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: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
  • Cc: pgsql-hackers(at)postgresql(dot)org
  • Subject: Re: file-locking and postmaster.pid
  • Date: Wed, 24 May 2006 18:53:11 -0400
  • Message-id: <1148511191(dot)16791(dot)1(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.

Well, you are wrong here.  We _want_ every backend to hold a shared
lock.  We need to stop a postmaster from starting if there is a backend
running that was started by a no-longer-running postmaster.

Oh... didn't know that.  How is that accomplished now? There must be some code beside the pid file check.

            -- 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