Re: semaphore usage "port based"? - Mailing list pgsql-hackers

From Max Khon
Subject Re: semaphore usage "port based"?
Date
Msg-id 20060509111924.GD64148@samodelkin.net
Whole thread Raw
In response to Re: semaphore usage "port based"?  (Robert Watson <rwatson@FreeBSD.org>)
Responses Re: semaphore usage "port based"?
List pgsql-hackers
Hi!

On Mon, Apr 03, 2006 at 11:56:13PM +0100, Robert Watson wrote:

> >>This is why it's disabled by default, and the jail documentation 
> >>specifically advises of this possibility.  Excerpt below.
> >
> >Ah, I see, glad to see it's accurately documented.
> 
> As it has been for the last five years, I believe since introduction of the 
> setting to allow System V IPC to be used with documented limitations.
> 
> >Given the rather significant use of shared memory by Postgres it seems to 
> >me that jail'ing it under FBSD is unlikely to get you the kind of 
> >isolation between instances that you want (the assumption being that you 
> >want to avoid the possibility of a user under one jail impacting a user in 
> >another jail). As such, I'd suggest finding something else if you truely 
> >need that isolation for Postgres or dropping the jails entirely.
> >
> >Running the Postgres instances under different uids (as you'd probably 
> >expect to do anyway if not using the jails) is probably the right 
> >approach. Doing that and using jails would probably work, just don't 
> >delude yourself into thinking that you're safe from a malicious user in 
> >one jail.
> 
> Yes, there seems to be an awful lot of noise being made about the fact that 
> the system does, in fact, work exactly as documented, and that the 
> configuration being complained about is one that is specifically documented 
> as being unsupported and undesirable.
> 
> As commented elsewhere in this thread, currently, there is no 
> virtualization support for System V IPC in the FreeBSD Jail implementation. 
> That may change if/when someone implements it.  Until it's implemented, it 
> isn't going to be there, and the system won't behave as though it's there 
> no matter how much jumping up and down is done.

sysvipc has been implemented once, but it has been decided that it adds
unnecessary bloat. That's sad.

/fjoe


pgsql-hackers by date:

Previous
From: PFC
Date:
Subject: Re: [PERFORM] Big IN() clauses etc : feature proposal
Next
From: Dhanaraj M
Date:
Subject: Need a help - Performance issues