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

On Tue, Aug 11, 2026 at 9:37 PM Palak Chaturvedi
<chaturvedipalak1911(at)gmail(dot)com> wrote:
>
> Hi,
>
> The CF bot has been flagging the patch set as "Needs rebase" for the last day
> or so. The failure is not caused by any change on master -- v20260810-0001
> still applies cleanly on 1d1d7b0e9c9. The conflict is inside the series:
> v20260810-0003 (the smaps-walker diagnostic elog patch) was generated with
> 0001 as its parent, so it overlaps the same block in test_shmem.c that
> v20260810-0002 rewrites (the shared/private VMA check and the switch from
> int64 to long counters). Applied in order 0001 -> 0002 -> 0003, hunk #2 of
> 0003 rejects.
>
> 0003 was only meant as a temporary diagnostic to inspect /proc/self/smaps
> output while investigating the earlier 32-bit failure, and is not intended
> for commit. Dropping it removes the conflict.
>
> Attached is v20260811, just the two commits that are actually proposed for
> commit:
>
> v20260811-0001-Resizable-shared-memory-structures.patch
> v20260811-0002-test_shmem-make-resizable-shmem-tests-portable.patch
>
> Verified with `git am` on postgres/master @ 1d1d7b0e9c9; both apply cleanly
> and the test_shmem TAP suite (001_fixed_shmem_struct,
> 002_resizable_shmem_struct)
> passes locally.
>
> No code changes vs v20260810-0001 / v20260810-0002 -- the diffs are byte
> identical, only the diagnostic 0003 is dropped and the series is renumbered.

I think we should add a DEBUG elog to print the VMA line at least.
Please include it in 0002.

--
Best Wishes,
Ashutosh Bapat