On Thu, Apr 14, 2011 at 7:26 AM, A.M. <age...@themactionfaction.com> wrote: > From what I understood, the primary purpose of the SysV check was to protect > the shared memory from multiple stompers. The interlock was a neat > side-effect.
Not really - the purpose of the interlock is to protect the underlying data files. The nattch interlock allows us to be very confident that there isn't another postmaster running on the same data directory on the same machine, and that is extremely important. You've just about convinced me that it might not be a bad idea to add the fcntl() interlock in addition because, as you say, that has a chance of working even over NFS. But the interlock we have now is *extremely* reliable, and I think we'd need to get some other amazingly compelling benefit to consider changing it (even if we were convinced that the alternate method was also reliable). I don't see that there is one. Anyone running an existing version of PostgreSQL in an environment where they care *at all* about performance has already adjusted their SysV shm settings way up. The benefit of using POSIX shm is that in, say, PostgreSQL 9.2, it might be possible for shared buffers to have a somewhat higher default setting out of the box, and be further increased from there without kernel parameter changes. And there might be more benefits besides that, but certainly those by themselves seem pretty worthwhile. SysV shm is extremely portable, so I don't think that we're losing anything by continuing to allocate a small amount of it (a few kilobytes, perhaps) and just push everything else out into POSIX shm. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
