Hi,

On Wed, 26 Aug 2026 at 03:10, Heikki Linnakangas <[email protected]> wrote:

> On 21/08/2026 08:36, Ayush Tiwari wrote:
> > Looking at the after-startup path from 283e823f9dc, I noticed that
> > RegisterShmemCallbacks() does not do anything useful in single-user mode.
> > The branch that does the work immediately is guarded by:
> >
> >      if (shmem_request_state == SRS_DONE && IsUnderPostmaster)
> >
> > IsUnderPostmaster is false in a standalone backend as well as in the
> > postmaster, so a standalone backend always falls through to the "remember
> > the callbacks for later" branch, and startup has already consumed that
> > list.  An extension loaded at runtime there, e.g. with LOAD or CREATE
> > EXTENSION, therefore never has its callbacks called, and
> > RegisterShmemCallbacks() reports nothing:
> >
> >      LOG:  test_shmem module's _PG_init called
> >      ERROR:  shmem area not attached or initialized in this process
> >
> > The LOG line is the only trace of the registration.  The ERROR is
> > test_shmem's own guard when the area is later used, not the shmem code;
> > an extension without such a guard would dereference a NULL pointer?
> >
> > I am unsure whether this was left out intentionally or simply missed, but
> > it seems worth having: a standalone backend has shared memory and the
> > same after-startup reserve, and a silent no-op is easy to mistake for
> > success.
>
> That was an oversight, thanks for the testing!
>
> > The attached patch also checks !IsPostmasterEnvironment and adds a
> > single-user case to the test_shmem TAP test.
>
> Hmm, I think the check should be just "if (shmem_request_state ==
> SRS_DONE)", with an assert that it's not called from the postmaster. The
> reason it cannot be called from the postmaster after startup is that
> postmaster cannot acquire lwlocks.
>
> >       skip 'single-user mode is not supported on this platform', 1
> >         if $windows_os;
>
> Huh, we don't support single-user mode on Windows? /me looks around. We
> do, but apparently there are some issues with it in the CI. All other
> single-user tests are also skipped on Windows. Per commit 1f2e51e3c7:
>
> > These tests are skipped on Windows, as direct calls of
> >     postgres --single would fail on permission failures.  There is no
> >     platform-specific behavior that needs to be checked, so living with
> this
> >     restriction should be fine.  The CI is OK with that, now let's see
> what
> >     the buildfarm tells.
>
> Ok then I guess, but I'll copy the comment from that commit to explain
> why it's not run on Windows.
>
> See attached.
>

Thanks for the updated flow, it looks much better.

I think the new test may need to be moved earlier in the TAP script.  It
currently runs after shared_preload_libraries has been set to test_shmem,
so the standalone backend loads and initializes test_shmem during startup.
The later SELECT therefore uses an area that was already initialized,
rather than exercising after-startup registration.

Would it make sense to move that block just after the first $node->stop?

Regards,
Ayush

Reply via email to