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.
The attached patch also checks !IsPostmasterEnvironment and adds a
single-user case to the test_shmem TAP test.
Thoughts?
Regards,
Ayush
v1-0001-Fix-after-startup-shmem-allocation-in-single-user.patch
Description: Binary data
