Re: SHM ids (was running pgsql 7 under Jail'ed virtual machine on FreeBSD 4.2)
От | Tom Lane |
---|---|
Тема | Re: SHM ids (was running pgsql 7 under Jail'ed virtual machine on FreeBSD 4.2) |
Дата | |
Msg-id | 15339.978738281@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: SHM ids (was running pgsql 7 under Jail'ed virtual machine on FreeBSD 4.2) (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: SHM ids (was running pgsql 7 under Jail'ed virtual
machine on FreeBSD 4.2)
RE: SHM ids (was running pgsql 7 under Jail'ed virtual machine on FreeBSD 4.2) |
Список | pgsql-general |
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
В списке pgsql-general по дате отправления: