Re: Improvements and refactoring in shmem.c

On Fri, Jan 30, 2026 at 9:58 PM Heikki Linnakangas <hlinnaka(at)iki(dot)fi> wrote:
>
> On 30/01/2026 11:22, Ashutosh Bapat wrote:
> > On Thu, Jan 29, 2026 at 9:11 PM Ashutosh Bapat
> > <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com> 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