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

Re: initdb dies during IpcSemaphoreCreate under BSD jail

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Joel Burton" <joel(at)joelburton(dot)com>
Cc: "Alastair D'Silva" <deece(at)newmillennium(dot)net(dot)au>,"'Vince Vielhaber'" <vev(at)michvhf(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: initdb dies during IpcSemaphoreCreate under BSD jail
Date: 2002-03-27 06:51:12
Message-ID: 16859.1017211872@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
"Joel Burton" <joel(at)joelburton(dot)com> writes:
>> This will allow you to run a single postgres in a single jail only one
>> user would have access to it.  If you try to run more then one it will
>> try to use the same shared memory and crash.

> Is this, in fact, the case?

Unless BSD jails have very bizarre shared memory behavior, this is
nonsense.  PG can easily run multiple postmasters in the same machine
(there are currently four postmasters of different vintages alive on
the machine I'm typing this on).  Give each one a different database
directory and a unique port number, and you're good to go.

It might be that postmasters in different jails on the same machine
would have to be assigned different port numbers to keep them from
conflicting.  Don't know exactly how airtight a BSD jail is ...
but there is an interaction between port number and shared memory
key.  I can imagine that a jail that hides processes but not shared
memory segments might confuse our startup logic that tries to detect
whether an existing shared memory segment is safe to reuse or not.
Perhaps your ISP has seen failures of that type from trying to
start multiple postmasters on the same port number in different
jails.

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: Christopher Kings-LynneDate: 2002-03-27 07:12:10
Subject: contrib/tree/README.tree
Previous:From: Tom LaneDate: 2002-03-27 06:40:19
Subject: Re: RI triggers and schemas

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