On Apr 13, 2011, at 8:36 PM, Robert Haas wrote: > > I don't see why we need to get rid of SysV shared memory; needing less > of it seems just as good.
1. As long one keeps SysV shared memory around, the postgresql project has to maintain the annoying platform-specific document on how to configure the poorly named kernel parameters. If the SysV region is very small, that means I can run more postgresql instances within the same kernel limits, but one can still hit the limits. My patch allows the postgresql project to delete that page and the hassles with it. 2. My patch proves that SysV is wholly unnecessary. Are you attached to it? (Pun intended.) > > In answer to your off-list question, one of the principle ways I've > seen fcntl() locking fall over and die is when someone removes the > lock file. You might think that this could be avoided by picking > something important like pg_control as the log file, but it turns out > that doesn't really work: > > http://0pointer.de/blog/projects/locking.html > > Tom's point is valid too. Many storage appliances present themselves > as an NFS server, so it's very plausible for the data directory to be > on an NFS server, and there's no guarantee that flock() won't be > broken there. If our current interlock were known to be unreliable > also maybe we wouldn't care very much, but AFAICT it's been extremely > robust. Both you and Tom have somehow assumed that the patch alters current postgresql behavior. In fact, the opposite is true. I haven't changed any of the existing behavior. The "robust" behavior remains. I merely added fcntl interlocking on top of the lock file to replace the SysV shmem check. If someone deletes the postgresql lock file over NFS, the data directory is equally screwed, but with my patch there is chance that two machines sharing a properly-configured NFS mount can properly interlock- postgresql cannot offer that today, so this is a feature upgrade with no loss. The worst case scenario is today's behavior. My original goal remains to implement POSIX shared memory, but Tom Lane was right to point out that the current interlocking check relies on SysV, so, even though the startup locking is really orthogonal to shared memory, I implemented what could be considered a separate patch for that and rolled it into one. I would encourage you to take a look at the patch. Cheers, M -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
