Re: Remove PG_MMAP_FLAGS

On Fri, Jan 23, 2026 at 4:53 AM Michael Paquier <michael(at)paquier(dot)xyz> wrote:
>
> On Thu, Jan 22, 2026 at 02:17:08PM -0500, Tom Lane wrote:
> > Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com> writes:
> >> Over [1] Peter mentioned that PG_MMAP_FLAGS is not used for
> >> portability even though it's placed in portability/mem.h. That might
> >> have been the intention when it was added in
> >> b0fc0df9364d2d2d17c0162cf3b8b59f6cb09f67. But history does not show it
> >> being used that way at any point in time. Per suggestion removing that
> >> macro and instead using the flags directly in CreateAnonymousSegment()
> >> which is the only place where it's used.
> >
> > I think you attached the wrong patch? This one doesn't touch
> > PG_MMAP_FLAGS.

I didn't do a good job writing that email: attached wrong patch and
also didn't provide the required reference. Sorry for that. Corrected
in this email.

>
> PG_MMAP_FLAGS is still used in two places in sysv_shmem.c, where I
> guess the intention of Robert back in b0fc0df9364d was to not
> copy-paste the same flag values multiple times. I can still get the
> intention even today, so, if we were to do something, why don't you
> just make PG_MMAP_FLAGS local to sysv_shmem.c and call it a day?
>
> Honestly, I don't think that we should change this code at all: I also
> like the current idea of PG_MMAP_FLAGS being defined in the same place
> where we check for HASSEMAPHORE and ANONYMOUS, so it comes down to
> this being a matter of taste.

As Peter mentioned in the shared buffers resizing thread [1] it's
placement and name in mem.h led us to think that it affects all mmap
calls or that all mmap calls should use those flags. Neither of which
is true. We have different mmap calls using different set of flags.
Attached patch proposes changes similar (not exact) as you suggest
above. Please take a look.

[1] https://www.postgresql.org/message-id/12add41a-7625-4639-a394-a5563e349322@eisentraut.org

--
Best Wishes,
Ashutosh Bapat