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

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