What'd happen is: Operation not permitted (EPERM, -1), so its not a
problem...
-alex
On Fri, 5 Jan 2001, Tom Lane wrote:
> 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
>
>