Horton

Thread

Commits

  1. Remove PG_MMAP_FLAGS from mem.h

  2. Dramatically reduce System V shared memory consumption.

  1. Remove PG_MMAP_FLAGS

    Ashutosh Bapat <ashutosh.bapat.oss@gmail.com> — 2026-01-22T17:22:08Z

    Hi,
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.

PFA patch for the same.

-- 
Best Wishes,
Ashutosh Bapat

  2. Re: Remove PG_MMAP_FLAGS

    Tom Lane <tgl@sss.pgh.pa.us> — 2026-01-22T19:17:08Z

    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.

			regards, tom lane

  3. Re: Remove PG_MMAP_FLAGS

    Michael Paquier <michael@paquier.xyz> — 2026-01-22T23:23:11Z

    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

  4. Re: Remove PG_MMAP_FLAGS

    Ashutosh Bapat <ashutosh.bapat.oss@gmail.com> — 2026-01-23T02:34:18Z

    On Fri, Jan 23, 2026 at 4:53 AM Michael Paquier <michael@paquier.xyz> wrote:
>
> 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.

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

  5. Re: Remove PG_MMAP_FLAGS

    Michael Paquier <michael@paquier.xyz> — 2026-01-23T04:42:52Z

    On Fri, Jan 23, 2026 at 08:04:18AM +0530, Ashutosh Bapat wrote:
> 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

Okay, point taken.  I can live with your patch suggestion based on
what you have attached.
--
Michael

  6. Re: Remove PG_MMAP_FLAGS

    Ashutosh Bapat <ashutosh.bapat.oss@gmail.com> — 2026-01-23T10:03:33Z

    On Fri, Jan 23, 2026 at 10:12 AM Michael Paquier <michael@paquier.xyz> wrote:
>
> On Fri, Jan 23, 2026 at 08:04:18AM +0530, Ashutosh Bapat wrote:
> > 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
>
> Okay, point taken.  I can live with your patch suggestion based on
> what you have attached.

Thanks.

I revised the patch a bit. The macro had parenthesis around the macro
definition which are not required in the assignment. Removed them.
Also revised the commit message a bit.

-- 
Best Wishes,
Ashutosh Bapat

  7. Re: Remove PG_MMAP_FLAGS

    Michael Paquier <michael@paquier.xyz> — 2026-01-24T02:46:13Z

    On Fri, Jan 23, 2026 at 03:33:33PM +0530, Ashutosh Bapat wrote:
> I revised the patch a bit. The macro had parenthesis around the macro
> definition which are not required in the assignment. Removed them.
> Also revised the commit message a bit.

WFM.
--
Michael

  8. Re: Remove PG_MMAP_FLAGS

    Ashutosh Bapat <ashutosh.bapat.oss@gmail.com> — 2026-01-27T03:12:35Z

    On Sat, Jan 24, 2026 at 8:16 AM Michael Paquier <michael@paquier.xyz> wrote:
>
> On Fri, Jan 23, 2026 at 03:33:33PM +0530, Ashutosh Bapat wrote:
> > I revised the patch a bit. The macro had parenthesis around the macro
> > definition which are not required in the assignment. Removed them.
> > Also revised the commit message a bit.
>
> WFM.

Thanks a lot for taking care of this.

-- 
Best Wishes,
Ashutosh Bapat

  9. Re: Remove PG_MMAP_FLAGS

    Michael Paquier <michael@paquier.xyz> — 2026-01-27T07:09:44Z

    On Tue, Jan 27, 2026 at 08:42:35AM +0530, Ashutosh Bapat wrote:
> Thanks a lot for taking care of this.

Sure.  For the sake of the archives: c100340729b6.
--
Michael