Re: Better shared data structure management and resizable shared data structures

On 30/03/2026 07:50, Ashutosh Bapat wrote:
> On Sat, Mar 28, 2026 at 4:47 AM Heikki Linnakangas <hlinnaka(at)iki(dot)fi> wrote:
>> On 27/03/2026 09:01, Ashutosh Bapat wrote:
>>> /* Restore basic shared memory pointers */
>>> if (UsedShmemSegAddr != NULL)
>>> + {
>>> InitShmemAllocator(UsedShmemSegAddr);
>>> + ShmemCallRequestCallbacks();
>>>
>>> It's not clear how we keep the list of registered callbacks across the
>>> backends and also after restart in-sync. How do we make sure that the
>>> callbacks registered at this time are the same callbacks registered
>>> before creating the shared memory? How do we make sure that the
>>> callbacks registered after the startup are also registered after
>>> restart?
>>
>> On Unix systems, the registered callbacks are inherited by fork(), and
>> also survive over crash restart. With EXEC_BACKEND, the assumption is
>> that calling a library's _PG_init() function will register the same
>> callbacks every time. We make the same assumption today with the
>> shmem_startup hook.
>
> RegisterShmemCallbacks() may be called after the startup, and it will
> add new areas to the shared memory. How are those registries synced
> across the backends? From your answer below, those registries are not
> synced across backends. They will be wiped out by the restart and
> won't be registered again. Is that right? I think we need to document
> this fact and also the need to call RegisterShmemCallbacks() from all
> the backends where the new areas are required after the startup.

Correct. Ok, I'll add a note to comment on RegisterShmemCallbacks() to
call that out more explicitly, hope it helps.

- Heikki