Lamar Owen <lamar.owen@wgcr.org> writes:
> Tom fixed the bug with a slight kludge -- by touching the lock
> periodically, the problem is ameliorated for now. But as long as we
> have a persistent file in /tmp we will run into OS-dependent problems.
> I can see now a bug report that PostgreSQL is unreliable because it
> keeps crashing every x days
Kindly don't exaggerate the importance of this problem. We've been
running systems with the socketfiles in /tmp for years now, and we
know quite well what the downsides of that are. They're not that
drastic (unless you run a tmp-sweeper too stupid to distinguish socket
files from plain files, and even then you only see failure to connect).
Addition of the socket lockfile to the mix isn't increasing the risks
measurably that I can see. Even if a tmp-sweeper is enthusiastic enough
to remove a lockfile that the postmaster touches every few minutes, so
what? Client connections don't depend on the lockfile. The lockfile
only exists to protect against admin error, ie, starting a second
postmaster on the same socket --- which in routine operation won't
happen anyway.
The bottom line: yes, /tmp was a poor choice of place to put the
socket files. But no, it is not so poor as to be worth creating a
compatibility problem to fix it. Perhaps someday we will switch to
a whole new interface protocol (CORBA or whatever floats your boat),
and then we can let the whole mess drift off into the sunset. But
right now, there is almost nothing about our FE/BE protocol that
*isn't* a legacy decision --- and fixing it piecemeal at the cost of
a flag day for each fix is not worthwhile. IMHO anyway.
regards, tom lane