Giles Lean <[EMAIL PROTECTED]> writes:
> I'm certainly no fan of NFS locking, but if someone trusts their NFS
> client and server implementations enough to put their data on, they
> might as well trust it to get a single lock file for startup right
> too. IMHO. Your mileage may vary.
Well, my local man page for lockf() sez
The advisory record-locking capabilities of lockf() are implemented
throughout the network by the ``network lock daemon'' (see lockd(1M)).
If the file server crashes and is rebooted, the lock daemon attempts
to recover all locks associated with the crashed server. If a lock
cannot be reclaimed, the process that held the lock is issued a
SIGLOST signal.
and the lockd man page mentions that not only lockd but statd have to be
running locally *and* at the NFS server.
This sure sounds like file locking on NFS introduces additional
failure modes above and beyond what we have already.
Since the entire point of this locking exercise is to improve PG's
robustness, solutions that depend on other daemons not crashing
don't sound like a step forward to me. I'm willing to trust the local
kernel, but I get antsy if I have to trust more than that.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
