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 it's quite reasonable
to argue that a coordinated set of server processes should be able to see each
other, especially if they're running as the same user, in the same jail,
started at the same time.
We use the semaphore sets only within postgres server processes; we could
hardly expect client processes to be able to get at them, since in general
clients aren't on the same machine. The issue here, though, is that Marc is
trying to start multiple postgres servers in different jails, and in that
context the different postgres servers aren't "coordinated" in any real
sense. We'd prefer that they didn't interact at all, but they are
interacting because the SysV code isn't restricting IPC to occur only within
a jail.
BTW, Marc, it occurs to me that a workaround for you would be to create a
separate userid for postgres to run under in each jail; then the regular
protection mechanisms would prevent the different postmasters from
interfering with each others' semaphore sets. But I think that workaround
just makes it even clearer that the jail mechanism isn't behaving very
sanely.
Any multi-instance application that uses unvirtualized System V IPC must know
how to distinguish between those instances. This is true of any potential
communication mechanism used by multi-instance applications -- be it a command
line argument to specify an alternative configuration file, or a configuration
file that specifies alternative ports, working directories, mail spool
directories, etc. If you install two instances of sendmail, it requires some
configuration to teach them not to step all over each other, and this is not
an accident: if they try to use the same mail spools, ports, etc, things will
go badly. I can't imagine that PostgreSQL should be any different -- it has
to be pointed at what resources to use and how to use them -- some of that
will be a property of how it's written, and some how it's configured.
Presumably, running multiple instances of PostgreSQL in jails should not be
all that different from running multiple instances on any UNIX machine: they
must not overlap where shared resources are concerned.
How is PostgreSQL deciding what semaphores to use? Can it be instructed to
use non-colliding ones by specifying an alternative argument to pass to
ftok(), or ID to use directly?
I would, in general, consider the use of System V IPC across jails (as
opposed to in a single jail) unsupported, since it's not consistent with
the security model.
That'd be fine with me --- the problem here is that we've got unwanted
communication across jails. If, say, the jail ID were considered part of
semaphore keys, we'd be in fine shape.
Well, I think it's definitely unwanted communications, but until such time as
FreeBSD supports virtualizing the System V IPC name spaces, the fact that you
can communicate between jails when System V IPC support is turned on for the
jail shouldn't be a surprise, and should in fact be considered a feature.
However, if applications behave incorrectly when treading over each other
because either they aren't written to support specifying how not to walk over
each other, or if they are not configured to use that support, then they're
not going to behave well :-).
Robert N M Watson
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
