"Schmidt, Peter" <peter.schmidt@prismedia.com> writes:
>> Seems like this still means a single point of failure, ie the NFS box. So
>> what's the point?
> The idea is to have a failover for postmaster itself. I realize you stated
> that postmaster crashes are rare, but if the primary machine goes down we
> will want a secondary to come up with postmaster and other processes
> running.
I'm just wondering why you think that the NFS box will be more reliable
than either of the database-server boxes...
>> You could remove that check, perhaps, but then you'd have to remove the
> PID file manually anytime you had a postmaster crash.
> I don't want to touch postmaster.pid code, but I am working on similar code
> for a seperate lockfile. From what I understand, one of the only options is
> to use fcntl to lock a file on NFS mount. If I create the file, lock it, and
> postmaster machine dies, I'm hoping the lock will go away and the secondary
> will be able to lock it. That way I wouldn't need to manually remove
> it.
Hm. I dunno if fcntl works across NFS or not. Even if it does, I'll
bet the lock would not get released if the postmaster machine dies ---
AFAIK NFS does not have a notion of connections, so the NFS server would
be unlikely even to notice that one of its clients went away. What
mechanism are you planning to use to get the secondary machine to
realize that the primary has died and it needs to do something? Seems
like it might be better to rely on that mechanism for locking, too.
> Which brings me to another question - does postgres use file locking for
> isolation level or other database operations? If so, am I going to run into
> problems if the database is on NFS mount?
No, we don't use fcntl for locking (except for the Unix socket file, and
even that usage is going away in 7.1).
regards, tom lane