Re: semaphore usage "port based"? - Mailing list pgsql-hackers

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
existingset.                 * One would expect EEXIST, given that we said IPC_EXCL, but                 * perhaps we
couldget a permission violation instead?  Also,                 * EIDRM might occur if an old set is slated for
destructionbut                 * 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
systemcall 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
beexceeded.  You need to raise the "                                                 "respective kernel parameter.
Alternatively,reduce PostgreSQL's "                                                 "consumption of semaphores by
reducingits max_connections parameter "                                                 "(currently %d).\n"
    "The PostgreSQL documentation contains more information about "
"configuringyour 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