Received: from localhost (unknown [200.46.204.191]) by postgresql.org (Postfix) with ESMTP id C044A2E0078 for ; Wed, 16 Jan 2008 12:41:58 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.191]) (amavisd-maia, port 10024) with ESMTP id 48495-04 for ; Wed, 16 Jan 2008 12:41:49 -0400 (AST) Received: from defout.telus.net (defout.telus.net [204.209.205.55]) by postgresql.org (Postfix) with ESMTP id F0CD12E2F2C for ; Wed, 16 Jan 2008 12:41:48 -0400 (AST) Received: from localhost ([204.209.205.55]) by priv-edmwes48.telusplanet.net (InterMail vM.7.08.02.00 201-2186-121-20061213) with ESMTP id <20080116164142.SGOM3491.priv-edmwes48.telusplanet.net@localhost> for ; Wed, 16 Jan 2008 09:41:42 -0700 Received: from 209.17.179.1 ( [209.17.179.1]) as user a3a18850@204.209.205.54 by webmail.telus.net with HTTP; Wed, 16 Jan 2008 08:41:42 -0800 Message-ID: <1200501702.478e33c61b74e@webmail.telus.net> Date: Wed, 16 Jan 2008 08:41:42 -0800 From: Mischa Sandberg To: pgsql-hackers@postgresql.org Subject: postgresql in FreeBSD jails: proposal MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.1-cvs X-Originating-IP: 209.17.179.1 X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200801/655 X-Sequence-Number: 112929 Here (@sophos.com) we run machine cluster tests using FreeBSD jails. A jail is halfway between a chroot and a VM. Jails blow a number of assumptions about a unix environment: sysv ipc's are global to all jails; but a process can only "see" other processes also running in the jail. In fact, the quickest way to tell whether you're running in a jail is to test for process 1. PGSharedMemoryCreate chooses/reuses an ipc key in a reasonable way to cover previous postmasters crashing and leaving a shm seg behind, possibly with some backends still running. Unfortunately, with multiple jails running PG servers and (due to app limitations) all servers having same PGPORT, you get the situation that when jail#2 (,jail#3,...) server comes up, it: - detects that there is a shm seg with ipc key 5432001 - checks whether the associated postmaster process exists (with kill -0) - overwrites the segment created and being used by jail #1 There's a workaround (there always is) other than this patch, involving NAT translation so that the postmasters listen on different ports, but the outside world sees them each listening on 5432. But that seems somewhat circuitous. I've hacked sysv_shmem.c (in PG 8.0.9) to handle this problem. Given the trouble that postmaster goes to, to stop shm seg leakage, I'd like to solicit any opinions on the wisdom of this edge case. If this patch IS useful, what would be the right level of compile-time restriction ("#ifdef __FreeBSD__" ???) @@ -319,7 +319,8 @@ if (makePrivate) /* a standalone backend shouldn't do this */ continue; - + /* In a FreeBSD jail, you can't "kill -0" a postmaster + * running in a different jail, so the shm seg might + * still be in use. Safer to test nattch ? + */ + if (kill(1,0) && errno == ESRCH && !PGSharedMemoryIsInUse(0,NextShmSegID)) + continue; if ((memAddress = PGSharedMemoryAttach(NextShmemSegID, &shmid)) == NULL) continue; /* can't attach, not one of mine */ End of Patch.