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

On Wed, Dec 26, 2018 at 11:43 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com> writes:
> > Since it's not fixing a bug, we wouldn't back-patch that into existing
> > releases. But I agree that we should do something like this for
> > PostgreSQL 12, and I think we should make it user configurable.
>
> I'm -1 on making this user configurable via a GUC; that adds documentation
> and compatibility burdens that we don't need, for something of no value
> to 99.99% of users. The fact that the default would need to be
> platform-dependent just makes that tradeoff even worse. I think the other
> 0.01% who need to change the default (and are bright enough to be doing
> the right thing for the right reasons) could certainly handle something
> like a pg_config_manual.h control symbol --- see USE_PPC_LWARX_MUTEX_HINT
> for a precedent that I think applies well here. So I'd favor just doing
> it that way.

I disagree. I think there is a growing body of evidence that
b0fc0df9364d2d2d17c0162cf3b8b59f6cb09f67 killed performance on many
types of non-Linux systems. This is the first report I recall about
AIX, but there have been previous complaints about some BSD variants.

When I was working on developing that commit, I went and tried to find
out all of the different ways of getting some shared memory from
various operating systems and compared them. Anonymous shared memory
allocated via mmap() was the hands-down winner in almost every
respect: supported on many systems, no annoying operating system
limits, automatic deallocation when the last process exits. It had
the disadvantage that it didn't have an equivalent of nattch, which
meant that we had to keep a small System V segment around just for
that purpose, but otherwise it looked really good.

However, I only considered the situation from a functional point of
view. I never considered the possibility that the method used to
obtain shared memory from the operating system would affect the
performance of that shared memory. To my surprise, however, it does,
and on multiple operating systems from various parts of the UNIX
family tree. If I'd known that at the time, that commit probably would
not have gone into the tree in the form that it did. I suspect that
there would have been a loud clamor for configurability, and I think I
would have agreed.

You may be right that this is of no value to a high percentage our
users, but I think that's only because a high percentage of our users
run Linux or Windows, which happen not to be affected. I'm rather
proud, though, of PostgreSQL's long history of trying to be
cross-platform. Even if operating systems like AIX or BSD are a small
percentage of the overall user base, I think it's totally fair to add
a GUC which likely be helpful to a large percentage of those people,
and I think the GUC proposed here likely falls into that category.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company