On Wed, Apr 13, 2011 at 6:11 PM, A.M. <agentm@themactionfaction.com> 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.)
With all due respect, I think this is an unproductive conversation.
Your patch proves that SysV is wholly unnecessary only if we also
agree that fcntl() locking is just as reliable as the nattch
interlock, and Tom and I are trying to explain why we don't believe
that's the case. Saying that we're just wrong without responding to
our points substantively doesn't move the conversation forward.
In case it's not clear, here again is what we're concerned about: A
System V shm *cannot* be removed until nobody is attached to it. A
lock file can be removed, or the lock can be accidentally released by
the apparently innocuous operation of closing a file descriptor.
> 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
ontop of the lock file to replace the SysV shmem check.
This seems contradictory. If you replaced the SysV shmem check, then
it's not there, which means you altered the behavior.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company