On Mon, 3 Apr 2006, Tom Lane wrote:
That's a fair question, but in the context of the code I believe we are
behaving reasonably. The reason this code exists is to provide some
insurance against leaking semaphores when a postmaster process is terminated
unexpectedly (ye olde often-recommended-against "kill -9 postmaster", for
instance). If the PID returned by GETPID is nonexistent or belongs to a
process not owned by the postgres userid then we assume that the semaphore
set can be recycled. We could get fooled by PID recycling if the PID
returned by GETPID belongs to a postgres-owned process that isn't actually
the original owner, but the penalty is just that we'll fail to recycle
semaphores that could be released. Not very harmful, and not very probable
either, unless you're running postgres under a userid that's used for a lot
of other stuff too. There is not much risk of long-term leakage of many
semaphore sets, even if you've got lots of postmaster crashes going on
(which I sure hope you don't). The code is designed to retry the same
semaphore keys on each cycle of life, so you'd have to get fooled by chance
coincidence of existing PIDs every time over many cycles to have a severe
resource-leakage problem. (BTW, Marc, that's the reason for *not*
randomizing the key selection as you suggested.)
So I think the code is pretty bulletproof as long as it's in a system that
is behaving per SysV spec. The problem in the current FBSD situation is
that the jail mechanism is exposing semaphore sets across jails, but not
exposing the existence of the owning processes. That behavior is
inconsistent: if process A can affect the state of a sema set that process B
can see, it's surely unreasonable to pretend that A doesn't exist.
Maybe I've misunderstood the problem here -- is the use of the GETPID
operation occuring within a coordinated set of server processes, or does it
also occur between client and server processes? I think it's quite reasonable
to argue that a coordinated set of server processes should be able to see each
other, especially if they're running as the same user, in the same jail,
started at the same time. After all, coordinated server applications
frequently use signals to manage resources and perform asynchronous
notification (i.e., SIGCHLD, SIGHUP, etc). If we're talking about clients and
servers coordinating using the same System V IPC name space, I find myself
less sympathetic to the idea that otherwise unrelated processes on either side
of the IPC mechanism should be using out-of-band process operations to test
for mutual presence.
There has been occasional investigation of virtualizing the System V IPC name
space, but as you are no doubt aware, the name space doesn't lend itself to
virtualization, as it fails to be conveniently hierarchical, etc. This is
just another of the ways in which System V IPC offers quite useful IPC
services in less useful ways. I would, in general, consider the use of System
V IPC across jails (as opposed to in a single jail) unsupported, since it's
not consistent with the security model. However, I have doubts about the
behavioral dependency we're talking about above.
Robert N M Watson
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
