Trond Eivind Glomsrød wrote:
> Lamar Owen <lamar.owen@wgcr.org> writes:
> > Trond Eivind Glomsrød wrote:
> > > Not to sound scheptical, but since when did postgresql care about
> > > backwards compatiblity? Upgrading is already demanding a lot of
> > Upgrading is only one facet of backwards compatibility.
> I know. I just mentioned one consistently painful aspect of it.
Your pain is evident from the hyperbolic statement. I share your pain.
> 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...
But postmaster _doesn't_ expect the files to stay _between_
invocations.... :-) But your point is understood.
What about the X sockets, then? X might stay up 10+ days. X doesn't
just put one file there, either -- there's a whole directory there in
/tmp.
> > 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).
According to what Peter said, that could be difficult.
But, let me ask this: is it a good thing for PostgreSQL clients to have
hard-coded socket locations? (Good thing or not, it exists already, and
I know it does....)
I have another question of Peter, Tom, Bruce, or anyone -- is the
hard-coded socket location in libpq? If so, wouldn't a dynamically
loaded libpq.so bring this location in for _any_ precompiled, not
statically-linked, client? Or am I missing something else?
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11