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.

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to