From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Patrick Stählin <me(at)packi(dot)ch> |
Cc: | pgsql-bugs(at)lists(dot)postgresql(dot)org, 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-25 01:01:11 |
Message-ID: | aILXVzYNhVm-yl7o@paquier.xyz |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
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
From | Date | Subject | |
---|---|---|---|
Next Message | PG Bug reporting form | 2025-07-25 04:43:03 | BUG #18999: Equivalent queries processing WHERE IS NULL & WHERE IS NOT NULL produce mutually exclusive results |
Previous Message | Tom Lane | 2025-07-24 21:18:50 | Re: BUG #18998: No materialized views in INFORMATION_SCHEMA.TABLE_PRIVILEGES |