Re: Better shared data structure management and resizable shared data structures

On Sun, Apr 5, 2026 at 11:18 AM Ashutosh Bapat
<ashutosh(dot)bapat(dot)oss(at)gmail(dot)com> wrote:
>
>
> I will post my resizable shmem structures patch in a separate email in
> this thread but continue to review your patches.

I reviewed the SLRU patch. This is the first time I am looking at SLRU
code, so my review may not be sufficient. As far as I understand, the
patch faithfully copies the functionality from the old system to the
new system. I didn't find any issues there.

I think calls to SimpleLruRequest() reads much better than SimpleLruInit().

Both MultiXactShmemInit and MultiXactShmemAttach set
OldestMemberMXactId, OldestVisibleMXactId. In future if we add another
global variable to point to the shared memory, somebody needs to
remember to initialize it in both these functions. Maybe deduplicate
it with something like attached? Similarly for PredicateLock related
changes.

shmem_slru_init and shmem_slru_attach() also have the following
duplicate lines, which can be deduplicated in a similar fashion.
desc->shared = shared;
desc->nbanks = nbanks;
memcpy(&desc->options, options, sizeof(SlruOpts));

Including "access/slru.h" in shmem.h is circular inclusion. I am
wondering whether we need to create shmem_slru.h like shmem_hash.h to
handle shared memory APIs related to SLRU. Given that SLRU also has a
disk component, the bifurcation may not be straightforward. I haven't
looked into this aspect in detail.

--
Best Wishes,
Ashutosh Bapat