Re: shmem_startup_hook called twice on Windows

2025-09-18 Thread Nathan Bossart
On Mon, Sep 08, 2025 at 04:57:19PM -0500, Sami Imseih wrote: > v2 LGTM. Committed, thanks for reviewing. I ended up only back-patching the documentation fix, as the test_slru bug is pretty innocuous. -- nathan

Re: shmem_startup_hook called twice on Windows

2025-09-13 Thread Nathan Bossart
I quickly put together a patch for the stuff we've discussed in this thread. WDYT? -- nathan >From 11289e1e69fc7c6fdbe5a73483efc2daf1197ec9 Mon Sep 17 00:00:00 2001 From: Nathan Bossart Date: Mon, 8 Sep 2025 16:08:00 -0500 Subject: [PATCH v1 1/1] Fix shmem_startup_hook documentation. --- doc/

Re: shmem_startup_hook called twice on Windows

2025-09-11 Thread Sami Imseih
> Added in v2. v2 LGTM. -- Sami

Re: shmem_startup_hook called twice on Windows

2025-09-11 Thread Nathan Bossart
On Mon, Sep 08, 2025 at 04:31:43PM -0500, Sami Imseih wrote: > I still think we need to mention EXEC_BACKEND somehow. The way it's done > in [0], it says "On Windows (and anywhere else where EXEC_BACKEND is > defined)" > > So we do have precedent of mentioning EXEC_BACKEND in docs, and it’s > cle

Re: shmem_startup_hook called twice on Windows

2025-09-08 Thread Sami Imseih
> I quickly put together a patch for the stuff we've discussed in this > thread. WDYT? > > -- > nathan I still think we need to mention EXEC_BACKEND somehow. The way it's done in [0], it says "On Windows (and anywhere else where EXEC_BACKEND is defined)" So we do have precedent of mentioning EXE

Re: shmem_startup_hook called twice on Windows

2025-08-18 Thread Sami Imseih
> > "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 be

Re: shmem_startup_hook called twice on Windows

2025-08-15 Thread Nathan Bossart
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 o

Re: shmem_startup_hook called twice on Windows

2025-08-15 Thread Sami Imseih
> 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

Re: shmem_startup_hook called twice on Windows

2025-08-15 Thread Nathan Bossart
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

Re: shmem_startup_hook called twice on Windows

2025-08-15 Thread Sami Imseih
Sorry my last reply got mangled for some reason. Here it is again. > > Blame shows that this change was introduced in commit 69d903367c, > > but I could not determine the rationale from the discussion, > > so it may have been an oversight. > > I think the startup hook must run in each backend for

Re: shmem_startup_hook called twice on Windows

2025-08-15 Thread Sami Imseih
> While working on a related area, I noticed that shmem_startup_hook > is called twice under EXEC_BACKEND. > > The first call occurs in CreateSharedMemoryAndSemaphores() during > postmaster startup (!IsUnderPostmaster), which is expected. > > The second call happens in AttachSharedMemoryStructs() (

Re: shmem_startup_hook called twice on Windows

2025-08-15 Thread Nathan Bossart
On Fri, Aug 15, 2025 at 09:17:22AM -0500, Sami Imseih wrote: > While working on a related area, I noticed that shmem_startup_hook > is called twice under EXEC_BACKEND. > > The first call occurs in CreateSharedMemoryAndSemaphores() during > postmaster startup (!IsUnderPostmaster), which is expected