On Apr 13, 2011, at 9:30 PM, Robert Haas wrote:

> 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.

Sorry- it wasn't meant to be an attack- just a dumb pun. I am trying to argue 
that, even if the fcntl is unreliable, the startup procedure is just as 
reliable as it is now. The reasons being:

1) the SysV nattch method's primary purpose is to protect the shmem region. 
This is no longer necessary in my patch because the shared memory in unlinked 
immediately after creation, so only the initial postmaster and its children 
have access.

2) the standard postgresql lock file remains the same

Furthermore, there is indeed a case where the SysV nattch cannot work while the 
fcntl locking can indeed catch: if two separate machines have a postgresql data 
directory mounted over NFS, postgresql will currently allow both machines to 
start a postmaster in that directory because the SysV nattch check fails and 
then the pid in the lock file is the pid on the first machine, so postgresql 
will say "starting anyway". With fcntl locking, this can be fixed. SysV only 
has presence on one kernel.

> 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.

>From what I understood, the primary purpose of the SysV check was to protect 
>the shared memory from multiple stompers. The interlock was a neat 

The lock file contents are currently important to get the pid of a potential, 
conflicting postmaster. With the fcntl API, we can return a live conflicting 
PID (whether a postmaster or a stuck child), so that's an improvement. This 
could be used, for example, for STONITH, to reliably kill a dying replication 
clone- just loop on the pids returned from the lock.

Even if the fcntl check passes, the pid in the lock file is checked, so the 
lock file behavior remains the same.

If you were to implement a daemon with a shared data directory but no shared 
memory, how would implement the interlock? Would you still insist on SysV 
shmem? Unix daemons generally rely on lock files alone. Perhaps there is a 
different API on which we can agree.

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

Reply via email to