On Tue, 9 May 2006, Max Khon wrote:
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.
On Mon, 3 Apr 2006, Tom Lane wrote:
Robert Watson <[EMAIL PROTECTED]> writes:
Any multi-instance application that uses unvirtualized System V IPC must know
how to distinguish between those instances.
Sure.
How is PostgreSQL deciding what semaphores to use? Can it be instructed to
u
On Mon, 3 Apr 2006, Tom Lane wrote:
BTW, as long as we're annoying the freebsd-stable list with discussions of
workarounds, I'm wondering whether our shared memory code might have similar
risks. Does FBSD 6 also lie about the existence of other-jail processes
connected to a shared memory seg
On Mon, 3 Apr 2006, Tom Lane wrote:
That's a fair question, but in the context of the code I believe we are
behaving reasonably. The reason this code exists is to provide some
insurance against leaking semaphores when a postmaster process is terminated
unexpectedly (ye olde often-recommended
On Mon, 3 Apr 2006, Tom Lane wrote:
Robert Watson <[EMAIL PROTECTED]> writes:
Maybe I've misunderstood the problem here -- is the use of the GETPID
operation occuring within a coordinated set of server processes, or does it
also occur between client and server processes? I think
On Sun, 2 Apr 2006, Tom Lane wrote:
Oops. Here is the problem: kill() is lying by claiming there is no such
process as 83699. It looks to me like there in fact is such a process, but
it's in a different jail.
I venture that FBSD 6 has decided to return ESRCH (no such process) where
FBSD 4
On Mon, 3 Apr 2006, Stephen Frost 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
On Mon, 3 Apr 2006, Stephen Frost wrote:
So I think the code is pretty bulletproof as long as it's in a system that
is behaving per SysV spec. The problem in the current FBSD situation is
that the jail mechanism is exposing semaphore sets across jails, but not
exposing the existence of the o
