Tom Lane writes:
> There is a related issue on my todo list, though --- didn't we find out
> awhile back that some older Linux kernels crash and burn if one attempts
> to get an advisory lock on a socket file? (See thread 7/6/00) Were we
> going to fix that, and if so how? Or will we just tell people that they
> have to update their kernel to run Postgres? The current configure
> script "works around" this by disabling the advisory lock on *all*
> versions of Linux, which I regard as a completely unacceptable
> solution...
Firstly, AFAIK there's no official production kernel that fixes this.
When and if it gets fixed we can change that logic.
I have simple test program that exhibits the problem (taken from the
kernel mailing list), but
a) You shouldn't run test programs in configure.
b) You really shouldn't run test programs in configure that set up
networking connections.
c) You definitely shouldn't run test programs in configure that provoke
kernel exceptions.
We could use flock() on Linux, though.
Maybe we could name the socket file .s.PGSQL.port.pid and make
.s.PGSQL.port a symlink. Then you can find out whether the postmaster
that created the file is still running. (You could even put the actual
socket file into the data directory, although that would require
re-thinking the file permissions on the latter.)
Actually, this turns out to be similar to what you wrote in
http://www.postgresql.org/mhonarc/pgsql-hackers/1998-08/msg00835.html
But we really should be fixing the IPC interlock with IPC_EXCL, but the
code changes look to be non-trivial.
--
Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
