On Thu, Aug 27, 2009 at 02:38, Tom Lane<tgl@sss.pgh.pa.us> wrote:
>> I did have another thought. It could compare the time from uptime to
>> the timestamp on the lock file. If the server's been restarted since
>> the time in the lock file then it must be stale. uhm. unless clock's
>> been changed...
>
> Yeah, you can't trust system clocks too much either :-(.
>
> I was actually having second thoughts about the idea of using file
> locking. The only environment in which I've heard of file locks not
> being trustworthy is NFS, and if you're running a DB on NFS you've
> probably got worse problems than this one.
That is a bad generalization. A lot of people run their databases very
successfully on NFS. It just requires that you have a good NFS server,
know how to set it up, know how to set up your network, have a good
NFS client and know how to set *it* up.
Though I would assume that locks would be trustworthy in this case as well...
> Notably, if you mistakenly
> try to start postmasters on two different machines against the same
> NFS-mounted directory, the PID-based interlock will certainly fail, while
> file locking might save you.
That's in no way limited to NFS though... The difference being that in
a lot of other cases you just end up with a completely corrupt
filesystem :)
> So maybe we should take another look at
> that. Has anyone heard of other contexts in which file locks don't
> work? Has Windows got them?
Certainly: http://msdn.microsoft.com/en-us/library/aa365202%28VS.85%29.aspx
for example.
-- Magnus HaganderMe: http://www.hagander.net/Work: http://www.redpill-linpro.com/
