On Wed, Dec 26, 2018 at 11:43 AM Tom Lane <t...@sss.pgh.pa.us> wrote: > Thomas Munro <thomas.mu...@enterprisedb.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
