Re: postgresql in FreeBSD jails: proposal

Поиск
Список
Период
Сортировка
От Bruce Momjian
Тема Re: postgresql in FreeBSD jails: proposal
Дата
Msg-id 200803250211.m2P2BVn13115@momjian.us
обсуждение исходный текст
Ответ на postgresql in FreeBSD jails: proposal  (Mischa Sandberg <mischa_sandberg@telus.net>)
Ответы Re: postgresql in FreeBSD jails: proposal  (Alvaro Herrera <alvherre@commandprompt.com>)
Список pgsql-hackers
Added to TODO:

* Improve detection of shared memory segments being used by other FreeBSD jails
 http://archives.postgresql.org/pgsql-hackers/2008-01/msg00656.php


---------------------------------------------------------------------------

Mischa Sandberg wrote:
> Here (@sophos.com) we run machine cluster tests using FreeBSD jails. A
> jail is halfway between a chroot and a VM. Jails blow a number of
> assumptions about a unix environment: sysv ipc's are global to all
> jails; but a process can only "see" other processes also running in the
> jail. In fact, the quickest way to tell whether you're running in a jail
> is to test for process 1.
> 
> PGSharedMemoryCreate chooses/reuses an ipc key in a reasonable way to
> cover previous postmasters crashing and leaving a shm seg behind,
> possibly with some backends still running.
> 
> Unfortunately, with multiple jails running PG servers and (due to app
> limitations) all servers having same PGPORT, you get the situation that
> when jail#2 (,jail#3,...) server comes up, it:
> - detects that there is a shm seg with ipc key 5432001
> - checks whether the associated postmaster process exists (with kill -0)
> - overwrites the segment created and being used by jail #1
> 
> There's a workaround (there always is) other than this patch, involving
> NAT translation so that the postmasters listen on different ports, but
> the outside world sees them each listening on 5432. But that seems
> somewhat circuitous.
> 
> I've hacked sysv_shmem.c (in PG 8.0.9) to handle this problem. Given the
> trouble that postmaster goes to, to stop shm seg leakage, I'd like to
> solicit any opinions on the wisdom of this edge case. If this patch IS
> useful, what would be the right level of compile-time restriction
> ("#ifdef __FreeBSD__" ???)
> 
> @@ -319,7 +319,8 @@
>  
>                 if (makePrivate)                /* a standalone backend
> shouldn't do this */
>                         continue;
> -
> +               /* In a FreeBSD jail, you can't "kill -0" a postmaster
> +                * running in a different jail, so the shm seg might
> +                * still be in use. Safer to test nattch ?
> +                */
> +               if (kill(1,0) && errno == ESRCH &&
> !PGSharedMemoryIsInUse(0,NextShmSegID))
> +                       continue;
>                 if ((memAddress = PGSharedMemoryAttach(NextShmemSegID,
> &shmid)) == NULL)
>                         continue;                       /* can't attach,
> not one of mine */
>  
> End of Patch.
> 
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 1: if posting/reading through Usenet, please send an appropriate
>        subscribe-nomail command to majordomo@postgresql.org so that your
>        message can get through to the mailing list cleanly

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://postgres.enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: [pgsql-www] New email list for emergency communications
Следующее
От: mx
Дата:
Сообщение: Re: [GSoC] (Is it OK to choose items without % mark in theToDoList) && (is it an acceptable idea to build index on Flash Disk)