Larry Rosenman <ler@lerctr.org> writes:
> * Tom Lane <tgl@sss.pgh.pa.us> [001125 16:37]:
>> This story does indicate that we need a less fragile interlock against
>> starting two postmasters on one database. I have to admit that it
>> hadn't occurred to me that you could break the port-number interlock
>> so easily as that :-(. But obviously you can, so we need a different
>> way of representing the interlock. Hackers, any thoughts?
> how about a .pid/.port/.??? file in the /data directory, and a lock on that?
Nope, 'cause it wouldn't protect you against two postmasters in
different data directories trying to use the same port number.
The port-number lock has to use a system-wide mechanism.
You may want to go back and review the previous threads that have
discussed interlock issues. We have really three independent resources
that we have to ensure only one postmaster is using at a time:
1. Port number (for Unix socket, IP address, etc)
2. Data directory (database files)
3. Shared memory.
Up to now shared memory has been protected more or less implicitly
by the port-number lock, since the shared memory IPC key is derived
from the port number. However, the "virtual host" patch that we
recently accepted (way prematurely IMHO) breaks that correspondence.
I suspect that we really ought to try to have an independent interlock
on the shared memory block itself. There was a thread around 4/30/00
concerning changing the way that shmem IPC keys are generated, and
maybe that would address this concern.
If we weren't relying on port number to protect shared memory, I think
the existing interlocks on port would be sufficient. The kernel
enforces an interlock on listening to the same IP address, so that's
OK, and an advisory lock on the socket file is OK for preventing two
postmasters from listening to the same socket file. (There's no real
reason to prevent postmasters from using similarly-socket-numbered
socket files in different directories, other than the shmem key issue,
so a lock on the socket file is really just what we want for that
specific resource.)
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...
regards, tom lane
