On Sun, Apr 5, 2026 at 11:18 AM Ashutosh Bapat <[email protected]> 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
0014_edits.diff.nocibot
Description: Binary data
