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

Re: Re: Sure enough, the lock file is gone

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Lamar Owen <lamar(dot)owen(at)wgcr(dot)org>
Cc: The Hermit Hacker <scrappy(at)hub(dot)org>, Oliver Elphick <olly(at)lfix(dot)co(dot)uk>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Re: Sure enough, the lock file is gone
Date: 2001-01-29 04:11:19
Message-ID: 12090.980741479@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Lamar Owen <lamar(dot)owen(at)wgcr(dot)org> writes:
> Tom fixed the bug with a slight kludge -- by touching the lock
> periodically, the problem is ameliorated for now.  But as long as we
> have a persistent file in /tmp we will run into OS-dependent problems. 
> I can see now a bug report that PostgreSQL is unreliable because it
> keeps crashing every x days

Kindly don't exaggerate the importance of this problem.  We've been
running systems with the socketfiles in /tmp for years now, and we
know quite well what the downsides of that are.  They're not that
drastic (unless you run a tmp-sweeper too stupid to distinguish socket
files from plain files, and even then you only see failure to connect).

Addition of the socket lockfile to the mix isn't increasing the risks
measurably that I can see.  Even if a tmp-sweeper is enthusiastic enough
to remove a lockfile that the postmaster touches every few minutes, so
what?  Client connections don't depend on the lockfile.  The lockfile
only exists to protect against admin error, ie, starting a second
postmaster on the same socket --- which in routine operation won't
happen anyway.

The bottom line: yes, /tmp was a poor choice of place to put the
socket files.  But no, it is not so poor as to be worth creating a
compatibility problem to fix it.  Perhaps someday we will switch to
a whole new interface protocol (CORBA or whatever floats your boat),
and then we can let the whole mess drift off into the sunset.  But
right now, there is almost nothing about our FE/BE protocol that
*isn't* a legacy decision --- and fixing it piecemeal at the cost of
a flag day for each fix is not worthwhile.  IMHO anyway.

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: Bruce MomjianDate: 2001-01-29 04:24:03
Subject: Re: Re: Sure enough, the lock file is gone
Previous:From: Lamar OwenDate: 2001-01-29 04:01:29
Subject: Re: Beta4 available ...

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