Re: BUG #18996: Assertion fails in waiteventset.c when dropping database in single mode in PG18 - Mailing list pgsql-bugs

From Patrick Stählin
Subject Re: BUG #18996: Assertion fails in waiteventset.c when dropping database in single mode in PG18
Date
Msg-id 32f9406b-d3c7-4dd4-9027-d72c116d199d@packi.ch
Whole thread Raw
In response to BUG #18996: Assertion fails in waiteventset.c when dropping database in single mode in PG18  (PG Bug reporting form <noreply@postgresql.org>)
Responses Re: BUG #18996: Assertion fails in waiteventset.c when dropping database in single mode in PG18
List pgsql-bugs
Hi!

On 7/24/25 11:49 AM, PG Bug reporting form wrote:
> 
> We're starting to incorporate PG18 (REL_18_BETA2) in our builds/testing. Our
> tests currently fail because we drop the postgres database in single mode
> before we give our customers access to them, as they won't have superuser
> access and we allow them to re-create that database. It also triggers when I
> create a database foo and then drop it so it's not related to the postgres
> database specifically. The assert doesn't trigger with REL_17_5 built with
> the same instructions.

We, or rather git bisect, traced it down to commit 
84e5b2f07a5e8ba983ff0f6e71b063b27f45f346 that added a new wait event in 
InitializeLatchWaitSet if we're running under postmaster but then didn't 
add the same check in WaitLatch and always referenced it. This probably 
caused the assert later on, when we were waiting on the ProcBarrier.

I've attached a patch based on REL_18_STABLE that seems to fix the issue 
for us and passes the selftests.

Thanks,
Patrick
Attachment

pgsql-bugs by date:

Previous
From: Amit Kapila
Date:
Subject: Re: BUG #18897: Logical replication conflict after using pg_createsubscriber under heavy load
Next
From: Hugo DUBOIS
Date:
Subject: Unexpected Standby Shutdown on sync_replication_slots change