Date: Sun, 2 Apr 2006 21:56:32 -0300 (ADT) From: "Marc G. Fournier" <scrappy@postgresql.org> To: Tom Lane <tgl@sss.pgh.pa.us> Cc: pgsql-hackers@postgresql.org, freebsd-stable@freebsd.org, Kris Kennaway <kris@obsecurity.org> Subject: Re: [HACKERS] semaphore usage "port based"? Message-ID: <20060402213921.V947@ganymede.hub.org> In-Reply-To: <25526.1144017388@sss.pgh.pa.us> References: <20060402163504.T947@ganymede.hub.org> <25422.1144016604@sss.pgh.pa.us> <25526.1144017388@sss.pgh.pa.us>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 2 Apr 2006, Tom Lane wrote:
> I wrote:
>> Look at IpcSemaphoreCreate and InternalIpcSemaphoreCreate in
>> src/backend/port/sysv_sema.c. It may be worth stepping through them
>> with gdb to see what the semget calls are returning.
>
> BTW, even before doing that, you should look at "ipcs -s" output to try
> to get a clue what's going on. The EINVAL failures may be because the
> second postmaster to start deletes the semaphores created by the first
> one. You could easily see this happening in before-and-after ipcs data
> if so.
You are right ...
Before:
Semaphores:
T ID KEY MODE OWNER GROUP CREATOR CGROUP NSEMS OTIME CTIME
s 524288 5432001 --rw------- 70 70 70 70 17 14:44:19 14:44:19
s 524289 5432002 --rw------- 70 70 70 70 17 14:44:19 14:44:19
s 524290 5432003 --rw------- 70 70 70 70 17 14:44:19 14:44:19
s 524291 5432004 --rw------- 70 70 70 70 17 14:44:19 14:44:19
s 524292 5432005 --rw------- 70 70 70 70 17 14:44:19 14:44:19
s 524293 5432006 --rw------- 70 70 70 70 17 20:23:56 14:44:19
s 524294 5432007 --rw------- 70 70 70 70 17 20:23:58 14:44:19
After:
Semaphores:
T ID KEY MODE OWNER GROUP CREATOR CGROUP NSEMS OTIME CTIME
s 589824 5432001 --rw------- 70 70 70 70 17 21:38:03 21:38:03
s 589825 5432002 --rw------- 70 70 70 70 17 21:38:03 21:38:03
s 589826 5432003 --rw------- 70 70 70 70 17 21:38:03 21:38:03
s 589827 5432004 --rw------- 70 70 70 70 17 21:38:03 21:38:03
s 589828 5432005 --rw------- 70 70 70 70 17 21:38:03 21:38:03
s 589829 5432006 --rw------- 70 70 70 70 17 21:38:03 21:38:03
s 589830 5432007 --rw------- 70 70 70 70 17 21:38:03 21:38:03
So, our semget() is trying to acquire 5432001, FreeBSD's semget is
reporting back that its not in use, so the second instance if basically
'punting' the original one off of it ...
Kris, from the PostgreSQL sources, here is where we try and set the semId
to use ... is there something we are doing wrong with our code as far as
FreeBSD 6.x is concerned, such that semget is not returning a negative
value when the key is already in use? Or is there a problem with semget()
in a jail such that it is allowing for the KEY to be reused, instead of
returning a negative value?
========
static IpcSemaphoreId
InternalIpcSemaphoreCreate(IpcSemaphoreKey semKey, int numSems)
{
int semId;
semId = semget(semKey, numSems, IPC_CREAT | IPC_EXCL | IPCProtection);
if (semId < 0)
{
/*
* Fail quietly if error indicates a collision with existing set.
* One would expect EEXIST, given that we said IPC_EXCL, but
* perhaps we could get a permission violation instead? Also,
* EIDRM might occur if an old set is slated for destruction but
* not gone yet.
*/
if (errno == EEXIST || errno == EACCES
#ifdef EIDRM
|| errno == EIDRM
#endif
)
return -1;
/*
* Else complain and abort
*/
ereport(FATAL,
(errmsg("could not create semaphores: %m"),
errdetail("Failed system call was semget(%d, %d, 0%o).",
(int) semKey, numSems,
IPC_CREAT | IPC_EXCL | IPCProtection),
(errno == ENOSPC) ?
errhint("This error does *not* mean that you have run out of disk space.\n"
"It occurs when either the system limit for the maximum number of "
"semaphore sets (SEMMNI), or the system wide maximum number of "
"semaphores (SEMMNS), would be exceeded. You need to raise the "
"respective kernel parameter. Alternatively, reduce PostgreSQL's "
"consumption of semaphores by reducing its max_connections parameter "
"(currently %d).\n"
"The PostgreSQL documentation contains more information about "
"configuring your system for PostgreSQL.",
MaxBackends) : 0));
}
return semId;
}
========
----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060402213921.V947>