Skip site navigation (1) Skip section navigation (2)

Peripheral Links

Header And Logo

PostgreSQL
| The world's most advanced open source database.

Site Navigation

Search for
  Advanced Search

Re: file-locking and postmaster.pid


  • From: korry <korry(at)appx(dot)com>
  • To: pgsql-hackers(at)postgresql(dot)org
  • Subject: Re: file-locking and postmaster.pid
  • Date: Wed, 24 May 2006 18:34:30 -0400
  • Message-id: <1148510070(dot)21335(dot)97(dot)camel(at)sakai(dot)localdomain>

> You never need to reduce it to a shared lock.  On postmaster startup,
> try to lock the sentinel byte (one byte past the end-of-file).  If you
> can lock it, you know that no other postmaster has that byte locked.  If
> you can't lock it, another postmaster is running. It is an atomic
> operation. 

This doesn't work if the postmaster dies but a backend continues to run,
which is arguably the most important case we need to protect against.

I may be confused here, but I don't see the problem - byte-range locks are not inherited across a fork.  A backend would never hold the lock, a backend would never even look for the lock.


> However, Tom may be correct about NFS locking, but I guess I'm surprised
> that anyone would care :-)

Quite a lot of people run NFS-mounted data directories ...

I'm happy to take your word for that, and I agree that if NFS is important and locking is brain-dead on NFS, then relying solely on a lock is unacceptable.


            -- Korry



Home | Main Index | Thread Index

Privacy Policy | PostgreSQL Archives hosted by Command Prompt, Inc. | Designed by tinysofa
Copyright © 1996 – 2008 PostgreSQL Global Development Group