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: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
