Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 03 Apr 2006 15:57:43 -0400
From:      Tom Lane <tgl@sss.pgh.pa.us>
To:        Stephen Frost <sfrost@snowman.net>
Cc:        freebsd-stable@FreeBSD.org, "Marc G. Fournier" <scrappy@postgresql.org>, pgsql-hackers@postgresql.org, Robert Watson <rwatson@FreeBSD.org>, Kris Kennaway <kris@obsecurity.org>
Subject:   Re: [HACKERS] semaphore usage "port based"? 
Message-ID:  <16158.1144094263@sss.pgh.pa.us>
In-Reply-To: <20060403194251.GF4474@ns.snowman.net> 
References:  <26796.1144028094@sss.pgh.pa.us> <20060402225204.U947@ganymede.hub.org> <26985.1144029657@sss.pgh.pa.us> <20060402231232.C947@ganymede.hub.org> <27148.1144030940@sss.pgh.pa.us> <20060402232832.M947@ganymede.hub.org> <20060402234459.Y947@ganymede.hub.org> <27417.1144033691@sss.pgh.pa.us> <20060403164139.D36756@fledge.watson.org> <14654.1144082224@sss.pgh.pa.us> <20060403194251.GF4474@ns.snowman.net>

next in thread | previous in thread | raw e-mail | index | archive | help
Stephen Frost <sfrost@snowman.net> 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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?16158.1144094263>