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

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

From: Lamar Owen <lamar(dot)owen(at)wgcr(dot)org>
To: Trond Eivind Glomsrød <teg(at)redhat(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Peter Eisentraut <peter_e(at)gmx(dot)net>, The Hermit Hacker <scrappy(at)hub(dot)org>, Florent Guillaume <efgeor(at)noos(dot)fr>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Re: Sure enough, the lock file is gone
Date: 2001-01-28 20:54:00
Message-ID: 3A7486E8.E382EF8E@wgcr.org (view raw or flat)
Thread:
Lists: pgsql-hackers
Trond Eivind Glomsrød wrote:
> 
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> 
> > It would probably be better if the socket files weren't in /tmp but in
> > a postgres-owned directory.  However, at this point we have a huge
> > backwards compatibility problem to overcome if we want to move the
> > socket files.
> 
> Not to sound scheptical, but since when did postgresql care about
> backwards compatiblity? Upgrading is already demanding a lot of
> knowledge from the user (including needing such information, which
> almost no other package do), this is just a minor change (the files
> are mostly used by bundled tools - any exceptions?)

Upgrading is only one facet of backwards compatibility.  When the fe-be
protocol was changed for 6.4.2 is a good example.  The SQL itself is
kept very backwards-compatible, on purpose. Things for
backwards-compatibility are not as bad as the upgrading situation would
seem to imply.

> > There is an option in 7.1 to support defining a different directory
> > for the socket files, but I doubt very many people will use it.
 
> I intend to, for the RPMs we ship.

Ok, why not fix tmpwatch instead?  Only the lock files break FHS -- the
sockets can go there by FHS, right?  Of course, our requirement that
they be in the same location sort of forces the issue.  But, 7.1 now
touches the locks enought to keep tmpwatch from blowing them out.

To where do you intend to move them to?  /var/lock/pgsql? 
/var/run/pgsql? (Or postgresql... I'm still not happy with that change
-- the configuration is much nicer, but now the 'postgresql' suffix is
fixed -- I'm probably going to have to patch that to pgsql, as I'm
already changing many things that I'd prefer to leave closer to what 7.0
had).

The change in question is the use of '/usr/share/postgresql' and
'/usr/include/postgresql' as part of the installation, rather than
allowing '/usr/share/pgsql' and '/usr/include/pgsql' .

O well -- I'm just going to have to see how it distills. I've not
received any complaints yet, but I expect many after final. :-(
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

In response to

Responses

pgsql-hackers by date

Next:From: Trond Eivind =?iso-8859-1?q?Glomsr=F8d?=Date: 2001-01-28 21:07:09
Subject: Re: Re: Sure enough, the lock file is gone
Previous:From: Olivier PRENANTDate: 2001-01-28 19:59:20
Subject: BLOB HOWTO??

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