Skip site navigation (1) Skip section navigation (2)

Re: Nameless IPC on POSIX systems

From: des(at)des(dot)no (=?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?=)
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-patches(at)postgresql(dot)org
Subject: Re: Nameless IPC on POSIX systems
Date: 2005-05-06 19:22:49
Message-ID: 86u0lgyx9y.fsf@xps.des.no (view raw or flat)
Thread:
Lists: pgsql-patches
Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> This is not acceptable in the slightest, because it offers no protection
> against the situation where the old postmaster has crashed but there are
> still live backends.  If a new postmaster and new backends are allowed
> to start in that situation, using a new shared memory segment, you
> *will* have major database corruption (eg, duplicate use of transaction
> IDs).

I assumed the backends would terminate if postmaster crashed, and that
"reattach" was only necessary for the EXEC_BACKEND case.

You can use file-backed shared memory instead.  You need a directory
which you know is writeable and unique to this instance, on a file
system with enough free space to accomodate the full size of the
shared memory segment.  DataDir is probably a good choice.  If the
file does not exist, you create it at startup.  If it does exist, you
map it in and perform the same checks as in the SysV case.

> The semaphore code may be functionally OK, but I'm not thrilled with the
> fact that it requires two open file descriptors per semaphore, which
> have to be passed down to each postmaster child process.  That's a lot
> of files if MaxBackends is large; not only does it constrain the number
> of file slots available for fd.c to use, but you run the risk of
> overflowing what an fd_set can handle, which I notice breaks this code
> :-(.

#define FD_SETSIZE BIG_NUMBER

Anyway, I'm not sure you fully understand the problem this patch
addresses.  It is currently impractical if not impossible to run
PostgreSQL in jails on FreeBSD, because:

 - SysV IPC is normally not allowed in jails, and must be explicitly
   enabled.

 - the namespace is global, not per-jail, so separate instances in
   separate jails risk collision (I believe there is a workaround for
   this in 8.0, but I haven't tested it)

 - even if collision is avoided, SysV IPC breaches the separation
   between jails, allowing anyone who manages to compromise one jail
   to crash or corrupt any process using SysV IPC in any other jail on
   the system.

DES
-- 
Dag-Erling Smørgrav - des(at)des(dot)no

In response to

Responses

pgsql-patches by date

Next:From: Tom LaneDate: 2005-05-06 19:51:24
Subject: Re: Nameless IPC on POSIX systems
Previous:From: Bruce MomjianDate: 2005-05-06 17:40:11
Subject: Re: [patch 0/6] pgcrypto update

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group