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

Lamar Owen <lamar(dot)owen(at)wgcr(dot)org> writes:

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

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.