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

On 04/04/2026 16:51, Matthias van de Meent wrote:
>> +++ b/src/include/storage/shmem.h
>> +/*
>> + * Shared memory is reserved and allocated in stages at postmaster startup,
>> + * and in EXEC_BACKEND mode, there's some extra work done to "attach" to them
>> + * at backend startup.  ShmemCallbacks holds callback functions that are
>> + * called at different stages.
>> + */
>> +typedef struct ShmemCallbacks
> 
> Maybe this should also have the opportunity for a (before_)shmem_exit callback?

Hmm, yeah, perhaps, but I'm going to skip that for now. We already have 
a mechanism for shmem-exit callbacks, and I'm not sure how that would 
plug into this. I think we can do that later if it turns out to be a 
good idea, and I don't think it changes the parts that's included in the 
patches now.

>> + * on-demaind in a backend.  If a subsystem sets this flag, the callbacks are
>> + * called immediately after registration, to initialize or attach to the
>> + * requested shared memory areas.
> 
> Ideally we only immediately call the callbacks if we're under
> postmaster, or in a standalone backend; we shouldn't allocate shmem
> for some preloaded libraries that set this flag, at least not ahead of
> loading all preload libraries.

Right, the SHMEM_CALLBACKS_ALLOW_AFTER_STARTUP flag doesn't do anything 
if called during shared_preload_libraries processing. I'll re-word the 
comment to clarify that.

> While it's mostly mechanical changes, it did make me notice the rather
> annoying allocation patterns by XLOGShmemRequest. It allocates various
> types of data in one go (which, in principle, is fine) but in doing so
> it adds its own alignment tricks etc, and I'm not super stoked about
> that. If time allows, could we clean that up?

I'm not going to cram it into these patches, but +1.

- Heikki