On Thu, Mar 12, 2026 at 2:41 PM Heikki Linnakangas <[email protected]> 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
