| From: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
|---|---|
| To: | Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>, Tomas Vondra <tomas(at)vondra(dot)me>, Peter Eisentraut <peter(at)eisentraut(dot)org> |
| Cc: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Dmitry Dolgov <9erthalion6(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org, Robert Haas <robertmhaas(at)gmail(dot)com>, chaturvedipalak1911(at)gmail(dot)com, Andres Freund <andres(at)anarazel(dot)de> |
| Subject: | Re: Changing shared_buffers without restart |
| Date: | 2026-02-07 23:44:05 |
| Message-ID: | 9ac6082a-2e30-4462-a260-1507452aa962@iki.fi |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2026-02-08 01:27:55 | Re: Add 64-bit XIDs into PostgreSQL 15 |
| Previous Message | Heikki Linnakangas | 2026-02-07 22:56:55 | Re: Add 64-bit XIDs into PostgreSQL 15 |