Re: BUG #18996: Assertion fails in waiteventset.c when dropping database in single mode in PG18

From: Patrick Stählin <me(at)packi(dot)ch>
To: pgsql-bugs(at)lists(dot)postgresql(dot)org
Cc: Heikki Linnakangas <heikki(dot)linnakangas(at)iki(dot)fi>
Subject: Re: BUG #18996: Assertion fails in waiteventset.c when dropping database in single mode in PG18
Date: 2025-07-24 13:46:12
Message-ID: 32f9406b-d3c7-4dd4-9027-d72c116d199d@packi.ch
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: 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 Content-Type Size
0001-Do-not-modify-wait-events-we-never-added.patch text/x-patch 1.5 KB

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Hugo DUBOIS 2025-07-24 13:54:00 Unexpected Standby Shutdown on sync_replication_slots change
Previous Message Amit Kapila 2025-07-24 10:49:02 Re: BUG #18897: Logical replication conflict after using pg_createsubscriber under heavy load