Re: POSIX shared memory redux

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
documenton how to configure the poorly named kernel parameters. If the SysV region is very small, that means I can run
morepostgresql instances within the same kernel limits, but one can still hit the limits. My patch allows the
postgresqlproject 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.
Ihaven't changed any of the existing behavior. The "robust" behavior remains. I merely added fcntl interlocking on top
ofthe lock file to replace the SysV shmem check. If someone deletes the postgresql lock file over NFS, the data
directoryis equally screwed, but with my patch there is chance that two machines sharing a properly-configured NFS
mountcan properly interlock- postgresql cannot offer that today, so this is a feature upgrade with no loss. The worst
casescenario is today's behavior. 

My original goal remains to implement POSIX shared memory, but Tom Lane was right to point out that the current
interlockingcheck relies on SysV, so, even though the startup locking is really orthogonal to shared memory, I
implementedwhat 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