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