Karl Denninger <karl@xxxxxxxxxxxxx> writes:
> $ initdb -D data-default
> ...
> creating template1 database in data-default/base/1 ... FATAL: could not
> create semaphores: Invalid argument
> DETAIL: Failed system call was semget(2, 17, 03600).
Hmm. On my Linux box, "man semget" says EINVAL means
EINVAL nsems is less than 0 or greater than the limit on the number of
semaphores per semaphore set (SEMMSL), or a semaphore set corre-
sponding to key already exists, and nsems is larger than the
number of semaphores in that set.
which agrees with the POSIX spec. Is FreeBSD the same?
Proceeding on the assumption that it is ...
17 is the same nsems value we've been using for donkey's years, so the
SEMMSL aspect of this seems unlikely to apply; what presumably is
happening is a collision with an existing semaphore's key. Our code is
prepared for that, but it expects a different error code in such cases,
either EEXIST or EACCES:
/*
* 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.
*/
It sounds like your kernel is returning EINVAL in preference to any of
those codes, which would be pretty broken. I do not want to make our code
treat EINVAL as meaning we should retry with a different key, because if
the problem is indeed the SEMMSL limit, we'd be in an infinite loop.
You can probably get past this for the moment if you can remove the
semaphore set with key 2, but I'd advise filing a FreeBSD kernel
bug about their choice of errno.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
