Stephen Frost <[EMAIL PROTECTED]> writes:
> Could this be handled sensibly by using SEM_UNDO? Just a thought.
Interesting thought, but I think it doesn't work for the special case
where the semaphore's "previous owner" is actually our same PID ---
which is actually the more commonly exercised path, since true
postmaster crashes are pretty rare. More commonly we're trying to
detach from and recreate our own shmem and semas following a backend
crash. We can special-case that pretty easily with the GETPID solution
(pid == ours is obviously not some other process's sema), but with
SEM_UNDO it wouldn't work right.
I'm also concerned about the portability risks of depending on SEM_UNDO.
I think a lot of systems set the semaphore-undo limits pretty small,
maybe even zero.
BTW, as long as we're annoying the freebsd-stable list with discussions
of workarounds, I'm wondering whether our shared memory code might have
similar risks. Does FBSD 6 also lie about the existence of other-jail
processes connected to a shared memory segment --- ie, in
shmctl(IPC_STAT)'s result, does shm_nattch count only processes in our
own jail?
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
