the jail can only address the PID's that operate within itself... in
effect allowing it to f'up its own enviroment only... thus the
problem with pg trying to allocate dedicated portions of the
host/system wide memory.
will up the 7.0.2 to 7.1 and give her another go around. Really would
like to work this within a jail'ed environment, but have much to much
code completed based on postgres to consider dumping it just because
of the functionality of the jail.
Dave
-----Original Message-----
From: pgsql-general-owner@postgresql.org
[mailto:pgsql-general-owner@postgresql.org]On Behalf Of Tom Lane
Sent: Friday, January 05, 2001 6:45 PM
To: Alex Pilosov
Cc: Dave VanAuken; pgsql-general@postgresql.org
Subject: Re: SHM ids (was running pgsql 7 under Jail'ed virtual
machine
on FreeBSD 4.2)
I said:
> Alex Pilosov <alex@pilosoft.com> writes:
>> I'd suggest you do this: add a global backend_shmid_offset in
ipc.c,
>> initialized to current default, and an option to postgres to put a
value
>> there.
> Don't waste your time. This issue is gone in current sources. See
> IpcMemoryCreate and IpcSemaphoreCreate in
src/backend/storage/ipc/ipc.c.
Actually, now that I think about it, you might still have a problem if
a "jail" is what I think it is. The current code will step past an
existing shmem segment if it appears to be a non-Postgres memory
segment
or if it appears to belong to another running postmaster. However,
the
test to see if the segment owner appears to be alive is
/*
* If the creator PID is my own PID or does not belong to any
* extant process, it's safe to zap it.
*/
if (hdr->creatorPID != getpid())
{
if (kill(hdr->creatorPID, 0) == 0 ||
errno != ESRCH)
{
// segment belongs to a live postmaster, so continue
}
}
So the question for you is, what will happen if kill() is given a PID
belonging to a process that's in a different "jail"? Will it return
some kind of permission failure, or will it claim that there is no
such PID (ie, return ESRCH)? If the latter, we still have a problem
...
regards, tom lane
