From owner-freebsd-stable@FreeBSD.ORG Mon Apr 3 19:57:48 2006 Return-Path: X-Original-To: freebsd-stable@FreeBSD.org Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 42C4D16A4D8 for ; Mon, 3 Apr 2006 19:57:48 +0000 (UTC) (envelope-from tgl@sss.pgh.pa.us) Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id BA0E243D49 for ; Mon, 3 Apr 2006 19:57:46 +0000 (GMT) (envelope-from tgl@sss.pgh.pa.us) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.13.6/8.13.6) with ESMTP id k33Jvh0P016159; Mon, 3 Apr 2006 15:57:43 -0400 (EDT) To: Stephen Frost 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> Comments: In-reply-to Stephen Frost message dated "Mon, 03 Apr 2006 15:42:51 -0400" Date: Mon, 03 Apr 2006 15:57:43 -0400 Message-ID: <16158.1144094263@sss.pgh.pa.us> From: Tom Lane Cc: freebsd-stable@FreeBSD.org, "Marc G. Fournier" , pgsql-hackers@postgresql.org, Robert Watson , Kris Kennaway Subject: Re: [HACKERS] semaphore usage "port based"? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2006 19:57:48 -0000 Stephen Frost 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