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

Re: [HACKERS] postmaster locking issues.

From: Peter T Mount <peter(at)retep(dot)org(dot)uk>
To: Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us>
Cc: Bill(dot)Allie(at)mug(dot)org, hackers(at)postgresql(dot)org
Subject: Re: [HACKERS] postmaster locking issues.
Date: 1998-10-11 08:47:31
Message-ID: Pine.LNX.3.96.981011094538.496x-100000@maidast.retep.org.uk (view raw or flat)
Thread:
Lists: pgsql-hackers
On Sat, 10 Oct 1998, Bruce Momjian wrote:

> > After looking into the issue of using PID file locks vs. flock/unlock, I have 
> > come to the following conclusions:
> > 
> > 1.  It is generally agreed that a PID lock file should replace the current me-
> >     thod of locking (fcntl based locking). (See the message thread with
> >     '[HACKERS] flock patch breaks things here' in the subject).
> > 
> > 2.  The purpose of the lock file is to prevent multiple postmasters from run-
> >     ning on the same port and database.
> > 
> > 3.  Two PID files will be necessary, one to prevent mulitple instances of post-
> >     masters from running against the same data base, and one to prevent 
> > multiple
> >     instances from using the same port.
> > 
> > 4.  The database lock will be located in the DATA directory being locked.
> > 
> > 5.  The port lock will be kept in '/var/opt/pgsql/lock/'.
> 
> Yes, except lock file should be kept in /tmp.  I don't have
> /var/opt/..., and I doubt others do either.

My RedHat system doesn't have /var/opt either. I'd agree with /tmp as
that's been in every unix style system I've used so far.

-- 
       Peter T Mount peter(at)retep(dot)org(dot)uk
      Main Homepage: http://www.retep.org.uk
PostgreSQL JDBC Faq: http://www.retep.org.uk/postgres
 Java PDF Generator: http://www.retep.org.uk/pdf


In response to

pgsql-hackers by date

Next:From: Paul A VixieDate: 1998-10-11 08:59:34
Subject: Re: inet/cidr/bind
Previous:From: Bruce MomjianDate: 1998-10-11 05:31:10
Subject: Re: [HACKERS] select * from ..;vacuum crashes

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group