On Fri, Apr 3, 2026 at 3:40 AM Matthias van de Meent <[email protected]> wrote: > > On Wed, 1 Apr 2026 at 20:17, Heikki Linnakangas <[email protected]> wrote: > > > > While I do think it's an improvement over the current APIs, the > improvement seems to be mostly concentrated in the RequestStruct/Hash > department, with only marginal improvements in RegisterShmemCallbacks. > I feel like it's missing the important part: I'd like > direct-from-_PG_init() ShmemRequestStruct/Hash calls. If > ShmemRequestStruct/Hash had a size callback as alternative to the size > field (which would then be called after preload_libraries finishes) > then that would be sufficient for most shmem allocations, and it'd > simplify shmem management for most subsystems. > We'd still need the shmem lifecycle hooks/RegisterShmemCallbacks to > allow conditionally allocated shmem areas (e.g. those used in aio), > but I think that, in general, we shouldn't need a separate callback > function just to get started registering shmem structures. > > I also noticed that ShmemCallbacks.%_arg are generally undocumented, > and I couldn't find any users in core (at the end of the patchset) > that actually use the argument. Could it be I missed something? > > I don't understand the use of ShmemStructDesc. They generally/always > are private to request_fn(), and their fields are used exclusively > inside the shmem mechanisms, with no reads of its fields that can't > already be deduced from context. Why do we need that struct > everywhere?
My resizable shared memory structure patches use it as a handle to the structure to be resized. -- Best Wishes, Ashutosh Bapat
