On 10/02/2026 17:23, Ashutosh Bapat wrote:
I didn't look too deeply but what's broken in the EXEC_BACKEND case?
Dunno, I didn't look too deeply either :-D. But I think it's just some silly bug, i.e. the design should work with EXEC_BACKEND.
-------------- /* This struct lives in shared memory */ typedef struct { int field; } FoobarSharedCtlData; static void FoobarShmemInit(void *arg); /* Descriptor for the shared memory area */ ShmemStructDesc FoobarShmemDesc = { .name = "Foobar subsystem", .size = sizeof(FoobarSharedCtlData), .init_fn = FoobarShmemInit, }; /* Pointer to the shared memory struct */ #define FoobarCtl ((FoobarSharedCtlData *) FoobarShmemDesc.ptr)I don't like this much since it limits the ability to debug. A macro is not present in the symbol table.
True, although FoobarShmemDesc would still be present in the symbol table.
How about something like attached? Once we do that we can make the ShmemStructDesc local to ShmemRegisterStruct() calls and construct them on the fly. There's no other use for them.
Works for me.
LGTM. One more comment. /* estimated size of the shmem index table (not a hard limit) */ #define SHMEM_INDEX_SIZE (64) What do you mean by "not a hard limit"?
That was just copy-pasted from existing code. (Don't look too deeply ;-) )
We will be limited by the number of entries in the array; a limit that doesn't exist in the earlier implementation. I mean one can easily have 100s of extensions loaded, each claiming a couple shared memory structures. How large do we expect the array to be? Maybe we should create a linked list which is converted to an array at the end of registration. The array and its size can be easily passed to the child through the launch backend as compared to the list. Looking at launch_backend changes, even that doesn't seem to be required since SubPostmasterMain() calls RegisterShmemStructs().
Or you can also just repalloc() a larger array if it fills up.
Also, do we want to discuss this in a thread of its own?
Makes sense. - Heikki
