On 19/09/2026 22:12, Ayush Tiwari wrote:
Hi,
I found two more shmem attachment issues in single-user mode after
the recent fixes. Patches attached.
With ShmemInitStruct(), a second call for the same name and size errors
out with "already initialized". We only look for the old allocation if
IsUnderPostmaster is true, so a standalone backend goes straight down
the allocation path again.
0001 drops that condition. It fixes postmaster-startup reattachment
too, which I did hesitate over at first. But AFAICS that was supported
before the refactoring, and it's what the legacy API still promises.
So I'd lean towards restoring that behaviour in both places. Is there
a reason not to? (The size and initialization checks are still there.)
Hmm, so the scenario is:
1. Start postgres in single-user mode
2. Load an extension that calls ShmemInitStruct() to alloc a shmem area
3. The extension calls ShmemInitStruct() again, to get a pointer to the
already-initialized area.
I didn't think of that scenario. There's no reason to not support that,
although it's pretty weird for an extension to do that. One use case
might be to have a shared struct between two cooperating extensions, so
that they both call ShmemInitStruct() to get a pointer to the same area.
I'm not aware of any extensions actually doing that, though.
I'll commit that fix, thanks!
The other one is a bit odd: ask for an existing area with
SHMEM_ATTACH_UNKNOWN_SIZE after startup in single-user mode, and we
tell you it "cannot be used during startup".
IIUC, the distinction we need here is whether we're still working out
the initial shmem requirements, not whether we have a postmaster.
0002 adds SRS_REQUESTING_AFTER_STARTUP for that. I couldn't see a clean
way to reuse SRS_REQUESTING without mixing those cases up.
I'm a bit on the fence about adding another state just for this.
With the PG19 release getting close, I thought I'd send this out for
feedback before spending more time iterating on it. Does the extra
state seem like the right approach?
Extra state sounds reasonable. Thanks, I'll take a closer look, and I'll
double-check all the other places in shmem.c where we use
IsUnderPostmaster, too.
The IsUnderPostmaster variable is deceptive. It's easy to forget about
single-user code, and incorrectly assume that IsUnderPostmaster == true
means you're a backend and IsUnderPostmaster == false means you're
postmaster. I think that's what happened to me here and with the
previous single-user mode bugs. I remember I've struggled to keep that
in mind in the past too. We should perhaps replace IsUnderPostmaster
with a three-valued enum or something (postmaster, backend, single-user
backend).
We got that wrong in pg_get_shmem_pagesize(), too, also in previous
versions:
backend> select * from pg_get_shmem_allocations_numa();
1: name (typeid = 25, len = -1, typmod = -1, byval = f)
2: numa_node (typeid = 23, len = 4, typmod = -1, byval = t)
3: size (typeid = 20, len = 8, typmod = -1, byval = t)
----
TRAP: failed Assert("IsUnderPostmaster"), File:
"../src/backend/storage/ipc/shmem.c", Line: 731, PID: 121579
- Heikki
