From: | Nathan Bossart <nathandbossart(at)gmail(dot)com> |
---|---|
To: | Sami Imseih <samimseih(at)gmail(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: shmem_startup_hook called twice on Windows |
Date: | 2025-08-15 18:46:39 |
Message-ID: | aJ-Aj3Ebecdrsnz3@nathan |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Aug 15, 2025 at 11:25:55AM -0500, Sami Imseih wrote:
> I noticed a few things where this behavior becomes very suspicious.
>
> For example, in pgss_startup_hook, every time startup_hook is run
> we take an exclusive LW lock. so, all backends now may be competing
> for that lock by nature of connection establishment.
I suspect there's enough overhead in connection establishment for
contention to be unlikely. In any case, I'm not aware of any complaints
about this.
> test_slru calls LWLockNewTrancheId inside that hook.
Hm. At first glance, that does seem bogus for EXEC_BACKEND builds. I
think the only side effect is extra tranche ID allocations and missing
tranche names, as SimpleLruInit() forgoes any shared memory initialization
in non-postmaster backends.
> So, this tells me that the caller needs to be aware of such caveats.
>
> I am thinking something like this:
>
> "Because this hook is executed by the postmaster and invoked by backends via
> EXEC_BACKEND, it is essential to ensure that any code intended to run only
> during postmaster startup is properly protected against repeated execution.
> This can be enforced by verifying !IsUnderPostmaster before invocation."
IMHO we should avoid talking about EXEC_BACKEND, etc. and instead make it
clear that hooks should be prepared to deal with concurrent invocations
from other backends. But taking a step back, I'm still not entirely clear
what this adds to the existing documentation, which is pretty direct about
the need for locking and how to avoid re-initializing.
--
nathan
From | Date | Subject | |
---|---|---|---|
Next Message | Masahiko Sawada | 2025-08-15 19:01:14 | Re: Fix for typo in UUIDv7 timestamp extraction |
Previous Message | Masahiko Sawada | 2025-08-15 18:44:53 | Re: Fix for typo in UUIDv7 timestamp extraction |