Re: Changing shared_buffers without restart

On 10/02/2026 17:23, Ashutosh Bapat wrote:
> I didn't look too deeply but what's broken in the EXEC_BACKEND case?

Dunno, I didn't look too deeply either :-D. But I think it's just some
silly bug, i.e. the design should work with EXEC_BACKEND.

>> --------------
>>
>> /* This struct lives in shared memory */
>> typedef struct
>> {
>> int field;
>> } FoobarSharedCtlData;
>>
>> static void FoobarShmemInit(void *arg);
>>
>> /* Descriptor for the shared memory area */
>> ShmemStructDesc FoobarShmemDesc = {
>> .name = "Foobar subsystem",
>> .size = sizeof(FoobarSharedCtlData),
>> .init_fn = FoobarShmemInit,
>> };
>>
>> /* Pointer to the shared memory struct */
>> #define FoobarCtl ((FoobarSharedCtlData *) FoobarShmemDesc.ptr)
>>
>
> I don't like this much since it limits the ability to debug. A macro
> is not present in the symbol table.

True, although FoobarShmemDesc would still be present in the symbol table.

> How about something like attached?
> Once we do that we can make the ShmemStructDesc local to
> ShmemRegisterStruct() calls and construct them on the fly. There's no
> other use for them.

Works for me.

> LGTM.
>
> One more comment.
> /* estimated size of the shmem index table (not a hard limit) */
> #define SHMEM_INDEX_SIZE (64)
>
> What do you mean by "not a hard limit"?

That was just copy-pasted from existing code. (Don't look too deeply ;-) )

> We will be limited by the number of entries in the array; a limit that
> doesn't exist in the earlier implementation. I mean one can easily
> have 100s of extensions loaded, each claiming a couple shared memory
> structures. How large do we expect the array to be? Maybe we should
> create a linked list which is converted to an array at the end of
> registration. The array and its size can be easily passed to the child
> through the launch backend as compared to the list. Looking at
> launch_backend changes, even that doesn't seem to be required since
> SubPostmasterMain() calls RegisterShmemStructs().

Or you can also just repalloc() a larger array if it fills up.

> Also, do we want to discuss this in a thread of its own?

Makes sense.

- Heikki