From: Mischa Sandberg <mischa_sandberg@telus.net>
To: pgsql-hackers@postgresql.org
Subject: postgresql in FreeBSD jails: proposal
Date: Wed, 16 Jan 2008 08:41:42 -0800
Message-ID: <1200501702.478e33c61b74e@webmail.telus.net> (raw)
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.
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-admin@postgresql.org
Cc: mischa_sandberg@telus.net, pgsql-hackers@postgresql.org
Subject: Re: postgresql in FreeBSD jails: proposal
In-Reply-To: <1200501702.478e33c61b74e@webmail.telus.net>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox