Re: [PATCH] Two remaining shmem attachment issues in single-user mode

On 24/09/2026 16:07, Ashutosh Bapat wrote:
> On Wed, Sep 23, 2026 at 6:50 PM Ayush Tiwari
> <ayushtiwari(dot)slg01(at)gmail(dot)com> wrote:
>>
>> On Wed, 23 Sept 2026 at 17:53, Heikki Linnakangas <hlinnaka(at)iki(dot)fi> wrote:
>>>
>>> On 19/09/2026 22:12, Ayush Tiwari wrote:
>>>> 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).
>
> If we do this, do we still need extra state?

I came up with a simpler idea: we can check "ShmemIndex == NULL" to know
if shared memory has already been initialized and we're in the "after
startup" case, or not. That feels like a pretty direct way of checking
for exactly the property we care about, without needing another state.

I also reworked the tests. I added a very generic test_shmem_register()
function that [registers a callback that] calls ShmemRequestStruct()
with given name and size. And then the perl script can call it with
different sizes, to test the "unknown-size" case, as well as trying to
attach with incorrect size etc. So most of the logic is now in the perl
script.

What do you think?

- Heikki