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

Lamar Owen <lamar.owen@wgcr.org> writes:

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

I know. I just mentioned one consistently painful aspect of it.

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

Because it wouldn't be a fix, it would be a "lets workaround one
specific app which does things in a bad way"-hack. /tmp isn't supposed
be more than that... storing things there for more than than 10 days?
Ouch.  

> Only the lock files break FHS 

Explictly, yes. However, FHS says /tmp is for temporary files. Also,
it says programs shouldn't count on data to be stored there between
invocations. 10+ days isn't temporary...
> To where do you intend to move them to?  /var/lock/pgsql? 
> /var/run/pgsql? 

Ideally, the locks should be in /var/lock/pgsql and the socket
somewhere else - like /var/lib/pgsql (our mysql packages do this, and
both of them are specified in /etc/my.cnf).

-- 
Trond Eivind Glomsrød
Red Hat, Inc.