Re: shmem_startup_hook called twice on Windows
От | Sami Imseih |
---|---|
Тема | Re: shmem_startup_hook called twice on Windows |
Дата | |
Msg-id | CAA5RZ0vaAuonaf12CeDddQJu5xKL+6xVyS+_q1+cH=33JXV82w@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: shmem_startup_hook called twice on Windows (Nathan Bossart <nathandbossart@gmail.com>) |
Ответы |
Re: shmem_startup_hook called twice on Windows
|
Список | 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
В списке pgsql-hackers по дате отправления: