Hi, On Sun, 20 Sept 2026 at 00:42, Ayush Tiwari <[email protected]> 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.) > > 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?
I've added this to commitfest for tracking purpose [1] I think the first one should be an open item too for PG 19? [haven't added it yet in that list] Regards, Ayush [1] https://commitfest.postgresql.org/patch/7320/
