On Thu, Aug 27, 2009 at 02:38, Tom Lane<t...@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 Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
