I had a look at this (v20260128), focusing on
v20260128-0002-Memory-and-address-space-management-for-bu.patch It
introduces a new concept of "segment id" and exposes that to various places:
+void *
+ShmemInitStructInSegment(const char *name, Size size, bool *foundPtr,
int segment_id)
So for each shmem struct, you now also specify 'segment_id'. (If you
call the old ShmemInitStruct() function, it defaults to MAIN_SHMEM_SEGMENT.)
I don't quite understand how you're supposed to use different segments
and when to use different "structs" in the same segment. The next patch
makes a segment resizeable:
+/*
+ * ShmemResizeStructInSegment -- Resize the given structure in shared
memory.
+ *
+ * This function resizes an existing shared memory structure while
preserving
+ * the existing memory location.
+ *
+ * Returns: pointer to the existing structure location, if the resize is
+ * successful, otherwise NULL.
+ */
+void *
+ShmemResizeStructInSegment(const char *name, Size size, bool *foundPtr,
+ int segment_id)
Ok, how does that actually work, if you allocate two structs in the
segment and start to resize them?
I think there's a tacit assumption here that if you want to be able to
resize a struct, it must be the only struct in the segment. If so,
what's the point of having a named struct in the segment in the first place?
I propose this API instead:
void
ShmemInitStructExt(const char *name, Size size, bool *foundPtr, bool
resizeable, Size max_size);
void *
ShmemResizeStruct(const char *name, Size size);
This completely hides the segment ids from the callers, it becomes
shmem.c's internal business. If you call ShmemInitStructExt with
resizeable==false, it can do the allocation from the main segment as
usual. But if you pass resizeable==true, then it creates a separate
segment for it, so that it can be resized.
What happens if you call ShmemInitStructExt() and the requested size
doesn't match the current size?
Could you write a standalone test module in src/test/modules to
demonstrate how to use the resizable shmem segments, please? That'd
allow focusing on that interface without worrying all the other
complexities of shared buffers.
- Heikki
