>> The only reason I see for the entire section is to detect if
>> it would be safe to unlink the socket because it's left by
>> another postmaster in case of abnormal termination. Tell me
>> if I've misread it.
That's exactly what it's for. We need to tell whether there is
still another postmaster running on the same port number. Too
bad the kernel is not bright enough to unlink the socket file
automatically when it's no longer in use...
>> So why not doing it on the Linux
>> platform different, using a separate file like
>> .s.PGSQL.5432.LCK?
I think it's a bad idea to do it differently on Linux than other
platforms. If we fix this (other than by just disabling the fcntl
call again on old Linuxen) we should use the new method everywhere.
> But how do you know if that file still belongs to an active postmaster?
> What if it exited before removing the file. Seems we would have to
> write the PID into the file, and do a kill() to see if it is running.
Well, if we wanted to continue to depend on fcntl(SETLK) then we could
use an empty plain file. I read the bug report as being that old Linux
kernels fail if fcntl(SETLK) is applied to a Unix-socket file. They'd
surely have noticed long before if the feature didn't work on plain
files.
But if we are going to change this at all, I'd vote for storing pids
in the lock files the way we are now doing in the data-directory pid
lock files. Then we wouldn't have to depend on fcntl at all, which
would be a Good Thing from a portability point of view.
However, I think it would be a really bad idea to keep the lock files
in /tmp --- that's way too open to accidental removals, not to mention
deliberate denial-of-service attacks. They need to be in a more secure
directory; but where? See the past discussions summarized in the
TODO.detail file.
regards, tom lane