Re: Shared Memory: How to use SYSV rather than MMAP ?

From: Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>
To: "REIX, Tony" <tony(dot)reix(at)atos(dot)net>
Cc: Andres Freund <andres(at)anarazel(dot)de>, Robert Haas <robertmhaas(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, "EMPEREUR-MOT, SYLVIE" <sylvie(dot)empereur-mot(at)atos(dot)net>
Subject: Re: Shared Memory: How to use SYSV rather than MMAP ?
Date: 2019-02-01 13:49:01
Views: Raw Message | Whole Thread | Download mbox
Lists: pgsql-hackers

Bonjour Tony,

On Sat, Jan 5, 2019 at 3:35 AM REIX, Tony <tony(dot)reix(at)atos(dot)net> wrote:
> Thanks for the 2 patches!
> I've seen also the discussion around this subject. Very interesting. Should I wait for a decision been taken? or should I study and experiment your patches before?

I am planning to commit the 0001 patch shortly, unless there are
objections. I attach a new version, which improves the documentation
a bit (cross-referencing the new GUC and the section on sysctl
settings). That will give us shared_memory_type = sysv.

Can you please try out the 0002 patch on AIX and see if it works, and
if not, tell us how to fix it? :-) The desired behaviour is:

1. If huge_pages = off, it doesn't use them.
2. ff huge_pages = try, it tries to use them, but if it can't
(perhaps because the Unix user doesn't have CAP_BYPASS_RAC_VMM
capability), it should fall back to non-huge page.
3. If huge_pages = on, it tries to use them, but if it can't it fails
to start up.

There may also be a case for supporting different page sizes
explicitly (huge_pages = 16GB?), but that could be done later.

Thomas Munro

Attachment Content-Type Size
0001-Add-shared_memory_type-GUC-v2.patch application/octet-stream 11.8 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2019-02-01 13:51:55 Re: Delay locking partitions during query execution
Previous Message Alvaro Herrera 2019-02-01 13:36:05 Re: [HACKERS] [PATCH] Generic type subscripting