On Fri, Jan 30, 2026 at 9:58 PM Heikki Linnakangas <[email protected]> wrote: > > On 30/01/2026 11:22, Ashutosh Bapat wrote: > > On Thu, Jan 29, 2026 at 9:11 PM Ashutosh Bapat > > <[email protected]> wrote: > >> A nitpick should content_offset be contentOffset (like totalSize) or > >> content_offset (like dsm_control)? I am ok either way. > > > > Huh, what was I looking at? there is no totalSize in PGShmemHeader. > > The new member's name fits the style of other names. Ignore this > > comment. > > Right. I renamed "freeoffset" to "free_offset", though, since we're > moving it to a different struct anyway. > > >> A minor discomfort I have is ShmemBase, which is the starting address > >> that the allocator will use, remains outside of ShmemAllocatorData(). > >> But it doesn't change once set so no need to "share" it through the > >> memory and also that will create a self-referencing pointer within the > >> shared memory. So it's fine. > > > > I think we can just get rid of ShmemBase and ShmemEnd. Their values > > can be derived from other variables at run time as done in the > > attached patch (0002). Alternatively, we could add them to > > ShmemAllocatorData itself to keep everything related to allocation > > together. But it's not really needed. > > > > I wanted to go as far as creating yet another structure to hold > > ShmemSegHdr and ShmemAllocator together. Having a structure will help > > in the shared buffer resizing project which needs multiple shared > > memory segments. But it can wait. > > > > What do you think? > > Meh, it doesn't feel much of an improvement to me. You're right that > ShmemBase and ShmemEnd can be derived, but it feels kind of nice to have > them as as explicit variables. > > So, pushed just the first patch, thanks!
Thanks. Closed the CF entry as committed. -- Best Wishes, Ashutosh Bapat
