Re: Remove PG_MMAP_FLAGS - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Remove PG_MMAP_FLAGS
Date
Msg-id aXKxX-tFjYJgyo_M@paquier.xyz
Whole thread Raw
In response to Re: Remove PG_MMAP_FLAGS  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Remove PG_MMAP_FLAGS
List pgsql-hackers
On Thu, Jan 22, 2026 at 02:17:08PM -0500, Tom Lane wrote:
> Ashutosh Bapat <ashutosh.bapat.oss@gmail.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.

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.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Refactor recovery conflict signaling a little
Next
From: Chao Li
Date:
Subject: Re: tablecmds: reject CLUSTER ON for partitioned tables earlier