On 29/01/2026 11:56, Ashutosh Bapat wrote:

0001: Adds assertions to InitShmemAccess() and InitShmemAllocation
which indicate the conditions, EXEC_BACKEND and IsUnderPostmaster,
these functions are expected to be called. I found these annotations
to be useful when modifying these functions to handle multiple Shmem
segments required by buffer pool resizing project [1].

0002: We use two different methods to pass ShmemIndex and ShmemLock
respectively to new backends even though both the structures are
allocated before creating named structures in the shared memory. This
patch consistently uses the same method - passing via PGShmemHeader.
Further the patch gets rid of InitShmemAllocation and moves that code
inside InitShmemAccess() itself. Maybe that's overkill but at least we
would be able to call InitShmemAllocation() from InitShmemAccess() and
declare first as static within shmem.c. That way we avoid a minor risk
of InitShmemAllocation() being called twice.

We may achieve consistency by passing ShmemIndex through
BackendParameter, but I haven't tried that.

Hmm, I agree it's inconsistent currently. And I'd like to reduce the use
of BackendParameters, I don't like that mechanism.

I don't much like moving the 'shmem_lock' pointer to PGShmemHeader
either though. It feels like a modularity violation, as no one else than
shmem.c should be accessing those fields. The same goes for the existing
'index' and 'freeoffset' fields really.

Also, does it make sense to have those fields in the "shim" shmem
segment that PGSharedMemoryCreate() creates? It's a little confusing, we
don't keep the 'freeoffset' in the shim up-to-date, for example.

One idea is to move all those fields to another struct, see attached.
What do you think?

@@ -35,6 +36,7 @@ typedef struct PGShmemHeader / standard header for all Postgres shmem /
Size freeoffset; / offset to first free space /
dsmhandle dsmcontrol; / ID of dynamic shared memory control seg /
void index; / pointer to ShmemIndex table */
+ slockt *shmemlock; / spinlock for shmem allocation /
#ifndef WIN32 / Windows doesn't have useful inode#s /
dev_t device; / device data directory is on /
ino_t inode; / inode number of data directory /

Could this contain the spinlock itself, instead of just a pointer to it?
Would be a little simpler. (That's moot if we go with my approach though)