From: | Sami Imseih <samimseih(at)gmail(dot)com> |
---|---|
To: | Nathan Bossart <nathandbossart(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 16:25:55 |
Message-ID: | CAA5RZ0vaAuonaf12CeDddQJu5xKL+6xVyS+_q1+cH=33JXV82w@mail.gmail.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> On Fri, Aug 15, 2025 at 10:36:47AM -0500, Sami Imseih wrote:
> > But that could potentially be dangerous if code in the startup hook gets
> > re-executed? I guess the doc below is giving a vague warning that one
> > should be careful what they put in that hook.
>
> The docs seem reasonably clear that these hooks need to be careful to not
> re-initialize shared memory that was already initialized by another backend
> [0].
>
> > Thanks, I missed the doc update. Yes, that is inconsistent between platforms,
> > and if we must live with this behavior, should the doc give a bigger warning
> > about the code that goes in that hook?
>
> The docs should definitely be updated for accuracy, but I'm not following
> what sort of additional warning you think we need. Could you share a
> concrete example of what you have in mind?
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.
test_slru calls LWLockNewTrancheId inside that hook.
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."
--
Sami
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2025-08-15 16:29:25 | Re: index prefetching |
Previous Message | Peter Geoghegan | 2025-08-15 16:24:40 | Re: index prefetching |