Re: shmem_startup_hook called twice on Windows
Nathan Bossart <nathandbossart@gmail.com>
From: Nathan Bossart <nathandbossart@gmail.com>
To: Sami Imseih <samimseih@gmail.com>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2025-08-15T18:46:39Z
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
Commits
-
Fix documentation for shmem_startup_hook.
- d96c854dfc63 19 (unreleased) landed
- a80b7a0547da 18.0 landed
- 778f391c26c6 17.7 landed
-
test_slru: Fix LWLock tranche allocation in EXEC_BACKEND builds.
- 530cfa8eb50c 19 (unreleased) landed
-
doc: Reorganize section for shared memory and LWLocks.
- 964152c476f2 17.0 cited
-
Refactor CreateSharedMemoryAndSemaphores
- 69d903367cde 17.0 cited