On Thu, Mar 12, 2026 at 2:41 PM Heikki Linnakangas <hlinnaka@iki.fi> wrote:
> shmem_startup_hook() is too late. The shmem structs need to be
> registered at postmaster startup before the shmem segment is allocated,
> so that we can calculate the total size needed.
Sorry, I meant shmem_request_hook.
> I'm currently leaning towards _PG_init(), except for allocations that
> depend on MaxBackends. For those, you can install a shmem_request_hook
> that sets the size in the descriptor. In other words, you can leave the
> 'size' as empty in _PG_init(), but set it later in the shmem_request_hook.
Why can't you just do the whole thing later?
> Another option is to add a new bespoken callback in the descriptor for
> such size adjustments, which would get called at the same time as
> shmem_request_hook. That might be a little more ergonomic, there would
> no longer be any need for extensions to use the old
> shmem_request/startup_hooks with the new ShmemRegisterStruct() mechanism.
Yeah, worth considering.
> Except that you'd still need them for RequestNamedLWLockTranche(). I
> wonder if we should recommend extensions to embed the LWLock struct into
> their shared memory struct and use the LWLockInitialize() and
> LWLockNewTrancheId() functions instead. That fits the new
> ShmemRegisterStruct() API a little better than RequestNamedLWLockTranche().
Yeah, I think RequestNamedLWLockTranche() might be fine if you just
need LWLocks, but if you need a bunch of resources, putting them all
into the same chunk of memory seems cleaner.
--
Robert Haas
EDB: http://www.enterprisedb.com
