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? Regards, Ayush
v1-0001-Fix-legacy-shmem-reattachment-in-single-user-mode.patch
Description: Binary data
v1-0002-Allow-unknown-size-shmem-attachments-in-single-user-mode.patch
Description: Binary data
