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

Trond Eivind Glomsrød wrote:
> Lamar Owen <lamar(dot)owen(at)wgcr(dot)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