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.
