On Wed, Apr 13, 2011 at 6:11 PM, A.M. <age...@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 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.)
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 on top 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
