Re: shmem_startup_hook called twice on Windows
Sami Imseih <samimseih@gmail.com>
From: Sami Imseih <samimseih@gmail.com>
To: Nathan Bossart <nathandbossart@gmail.com>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2025-08-18T22:05:00Z
Lists: pgsql-hackers
> > "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. I am not sure. I read this "" If this function sets foundPtr to false, the caller should proceed to initialize the contents of the reserved shared memory. If foundPtr is set to true, the shared memory was already initialized by another backend, and the caller need not initialize further. """ and it's related to ShmemInitStruct specifically. Imagine someone adds some code in there that does more than just ShmemInitStruct. This code will be run multiple times on EXEC_BACKEND vs once on !EXEC_BACKEND IMO, that is quite a large difference in behavior that should be clearly noted. -- Sami
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