Date: Mon, 3 Apr 2006 18:27:07 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: "Marc G. Fournier" <scrappy@postgresql.org> Cc: Daniel Eischen <deischen@freebsd.org>, freebsd-stable@freebsd.org, Andrew Thompson <thompsa@freebsd.org>, Kris Kennaway <kris@obsecurity.org> Subject: Re: [HACKERS] semaphore usage "port based"? Message-ID: <20060403182504.S76562@fledge.watson.org> In-Reply-To: <20060403140902.C947@ganymede.hub.org> References: <Pine.GSO.4.43.0604030817090.21105-100000@sea.ntplx.net> <20060403140902.C947@ganymede.hub.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 3 Apr 2006, Marc G. Fournier wrote: > The problem is that PostgreSQL uses kill(PID, 0) to determine whether or not > another process is running when it tries to allocate a semaphore ... > > for instance, when it starts up, it tries to semget(54320001); ... if that > fails, based on the PID that is attached to that semaphore, it tries to do a > kill(PID,0) ... if that fails, it then *takes over* that semaphore ... under > 4.x, kill(PID,0) *would* return that a process is running, even if it was in > another jail, altho the jail issuing the kill can't see that process, so > postgresql would go on to 54320002, and test that ... under FreeBSD 6.x, > kill(PID, 0) reports "not in use", so PostgreSQL stomps on that semaphore > ... Robert brought up a good point, about recycled PIDs, but Tom Lane's > response to that about the fact that we don't care if the process that is > running is the one *actually* holding the semaphore, we'd rather err on the > side of caution and just move on ... but we need to *know* that we need to > move on ... > > We don't need any more information about that process ID then that it is > "currently in use" ... nd I think that is where Andrew was coming from with > issueing EPERM rather then ESRCH ... The problem here is actually that two postgres instances are trying to use the same sempahore when they are actually different postgres instances. One of the postgres instances needs to be configured to use a different semaphore, since they can't share the semaphore. In the event we get virtualization of System V IPC, they can use the same semaphore ID to get different semaphores, but as long as the same ID points to the same sempahore for different instances, it's not going to work. As things stand, if you configure two different instances in two different jails, you need to use the same method you'd use to configure two different instances on the same UNIX host without jails. Does PGSQL have a way to specify the semaphore ID to use? Robert N M Watson
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060403182504.S76562>