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

Michael Paquier <michael@paquier.xyz>

From: Michael Paquier <michael@paquier.xyz>

To: Patrick Stählin <me@packi.ch>

Cc: pgsql-bugs@lists.postgresql.org, Heikki Linnakangas <heikki.linnakangas@iki.fi>

Date: 2025-07-25T01:01:11Z

Lists: pgsql-bugs

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

Fix assertion failure with latch wait in single-user mode
- f7dfccf9605d 18.0 landed
- 641f20d4c433 19 (unreleased) landed
Use ModifyWaitEvent to update exit_on_postmaster_death
- 84e5b2f07a5e 18.0 cited

On Thu, Jul 24, 2025 at 03:46:12PM +0200, Patrick Stählin wrote:
> 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.

That's the same kind of single-user-mode shortcut we have in the past
for similar issues, like 0ce5cf2ef24f for example.

@@ -187,9 +187,10 @@ WaitLatch(Latch *latch, int wakeEvents, long timeout,
     if (!(wakeEvents & WL_LATCH_SET))
         latch = NULL;
     ModifyWaitEvent(LatchWaitSet, LatchWaitSetLatchPos, WL_LATCH_SET, latch);
-    ModifyWaitEvent(LatchWaitSet, LatchWaitSetPostmasterDeathPos,
-                    (wakeEvents & (WL_EXIT_ON_PM_DEATH | WL_POSTMASTER_DEATH)),
-                    NULL);
+    if (IsUnderPostmaster)
+        ModifyWaitEvent(LatchWaitSet, LatchWaitSetPostmasterDeathPos,
+                        (wakeEvents & (WL_EXIT_ON_PM_DEATH | WL_POSTMASTER_DEATH)),
+                        NULL);

Yeah, that looks good to me.  It does not make sense to rely on that
for !IsUnderPostmaster, which is something that we obviously support
in WaitLatch() based on the assertion a couple of lines above while
the initialization happens.  Will fix, thanks for the report!
--
Michael