Re: Remove PG_MMAP_FLAGS

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Peter Eisentraut <peter(at)eisentraut(dot)org>
Subject: Re: Remove PG_MMAP_FLAGS
Date: 2026-01-22 23:23:11
Message-ID: aXKxX-tFjYJgyo_M@paquier.xyz
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Chao Li 2026-01-22 23:30:55 Re: tablecmds: reject CLUSTER ON for partitioned tables earlier
Previous Message Heikki Linnakangas 2026-01-22 23:20:20 Refactor recovery conflict signaling a little