Re: RegisterShmemCallbacks() does nothing in single-user mode

Hi,

On Wed, 26 Aug 2026 at 03:10, Heikki Linnakangas <hlinnaka(at)iki(dot)fi> 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