Re: Re: Sure enough, the lock file is gone - Mailing list pgsql-hackers

From Lamar Owen
Subject Re: Re: Sure enough, the lock file is gone
Date
Msg-id 3A7486E8.E382EF8E@wgcr.org
Whole thread Raw
In response to Re: Re: Sure enough, the lock file is gone  (Peter Eisentraut <peter_e@gmx.net>)
Responses Re: Re: Sure enough, the lock file is gone  (teg@redhat.com (Trond Eivind Glomsrød))
Re: Re: Sure enough, the lock file is gone  ("Oliver Elphick" <olly@lfix.co.uk>)
List pgsql-hackers
Trond Eivind Glomsrød wrote:
> 
> Tom Lane <tgl@sss.pgh.pa.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


pgsql-hackers by date:

Previous
From: Olivier PRENANT
Date:
Subject: BLOB HOWTO??
Next
From: teg@redhat.com (Trond Eivind Glomsrød)
Date:
Subject: Re: Re: Sure enough, the lock file is gone