Re: Better shared data structure management and resizable shared data structures
Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>
On Fri, Apr 3, 2026 at 3:40 AM Matthias van de Meent <boekewurm+postgres@gmail.com> wrote: > > On Wed, 1 Apr 2026 at 20:17, Heikki Linnakangas <hlinnaka@iki.fi> 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
Commits
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Tidy up #ifdef USE_INJECTION_POINTS guards
- 9480c585df6c 19 (unreleased) landed
-
Convert all remaining subsystems to use the new shmem allocation API
- 9b5acad3f40f 19 (unreleased) landed
-
Convert buffer manager to use the new shmem allocation functions
- a4b6139dcceb 19 (unreleased) landed
-
Add alignment option to ShmemRequestStruct()
- dacfe81a0de5 19 (unreleased) landed
-
Convert AIO to use the new shmem allocation functions
- 58a1573385ed 19 (unreleased) landed
-
Convert SLRUs to use the new shmem allocation functions
- 2e0943a8597e 19 (unreleased) landed
-
Refactor shmem initialization code in predicate.c
- 4c9eca5afea0 19 (unreleased) landed
-
Use the new shmem allocation functions in a few core subsystems
- c6d55714ba4c 19 (unreleased) landed
-
Convert lwlock.c to use the new shmem allocation functions
- a006bc7b1699 19 (unreleased) landed
-
Introduce a registry of built-in shmem subsystems
- 1fc2e9fbc0a3 19 (unreleased) landed
-
Convert pg_stat_statements to use the new shmem allocation functions
- d4885af3d653 19 (unreleased) landed
-
Add a test module to test after-startup shmem allocations
- 6409994c7dd8 19 (unreleased) landed
-
Introduce a new mechanism for registering shared memory areas
- 283e823f9dcb 19 (unreleased) landed
-
Move some code from shmem.c and shmem.h
- 6ef9bee29310 19 (unreleased) landed
-
Improve test_lwlock_tranches
- 92a685e4070d 19 (unreleased) landed
-
Test pg_stat_statements across crash restart
- 148fe2b05df5 19 (unreleased) landed
-
Refactor PredicateLockShmemInit to not reuse var for different things
- 3fd057772827 19 (unreleased) landed
-
Refactor ShmemIndex initialization
- 6b8238cb6aa7 19 (unreleased) landed
-
Add a new shmem_request_hook hook.
- 4f2400cb3f10 15.0 cited