Re: Improvements and refactoring in shmem.c

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!

- Heikki