Re: Changing shared_buffers without restart - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: Changing shared_buffers without restart
Date
Msg-id a22cfcd3-1c8d-41e7-9d89-7afd46eb6db1@iki.fi
Whole thread Raw
In response to Re: Changing shared_buffers without restart  (Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>)
List pgsql-hackers
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




pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Remove "struct" markers from varlena, varatt_external and varatt_indirect
Next
From: Ashutosh Bapat
Date:
Subject: Re: Report bytes and transactions actually sent downtream