BUG #16067: Failed system call was semget

On Sat, Oct 19, 2019 at 02:54:45PM +0000, PG Bug reporting form wrote:

The following bug has been logged on the website:

Bug reference: 16067
Logged by: chelsea lyu
Email address: chelsealyu@gmail.com
PostgreSQL version: 11.5
Operating system: MacOS
Description:

running bootstrap script ... 2019-10-19 23:25:15.095 JST [51410] FATAL:
could not create semaphores: No space left on device
2019-10-19 23:25:15.095 JST [51410] DETAIL: Failed system call was
semget(5432226, 17, 03600).

this is the code what I input, and then the problem is out.
MacBook-Pro:~ raye$ initdb /usr/local/var/postgres -E utf8

I also tried the code in the guide book of solving this question.
RAYEdeMacBook-Pro:~ raye$ sysctl -w kern.sysv.shmmax
kern.sysv.shmmax: 4194304
RAYEdeMacBook-Pro:~ raye$ sysctl -w kern.sysv.shmmin
kern.sysv.shmmin: 1
RAYEdeMacBook-Pro:~ raye$ sysctl -w kern.sysv.shmmni
kern.sysv.shmmni: 32
RAYEdeMacBook-Pro:~ raye$ sysctl -w kern.sysv.shmseg
kern.sysv.shmseg: 8
RAYEdeMacBook-Pro:~ raye$ sysctl -w kern.sysv.shmall
kern.sysv.shmall: 1024

but nothing happened.
it still cannot work.

I think you need to tweak kernel.sem, not the options for sysv shared memory.

Also, not a PostgreSQL bug, but an OS configuration issue ...

regards

--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

PG Bug reporting form <noreply@postgresql.org> writes:

Operating system: MacOS

running bootstrap script ... 2019-10-19 23:25:15.095 JST [51410] FATAL:
could not create semaphores: No space left on device
2019-10-19 23:25:15.095 JST [51410] DETAIL: Failed system call was
semget(5432226, 17, 03600).

That's a bit odd. macOS is known to have low default limits for
SysV shared memory, but not for semaphores. Which macOS version
are you running, exactly? What do you get from
sysctl -a | grep sysv.sem
? I get

kern.sysv.semmni: 87381
kern.sysv.semmns: 87381
kern.sysv.semmnu: 87381
kern.sysv.semmsl: 87381
kern.sysv.semume: 10

(and not only in Catalina, but very ancient mac versions)

Is it possible that something else is chewing up semaphores?
Looking at "sudo ipcs -s" output would reveal that.

I also tried the code in the guide book of solving this question.
RAYEdeMacBook-Pro:~ raye$ sysctl -w kern.sysv.shmmax
kern.sysv.shmmax: 4194304

That is not about this problem.

regards, tom lane

On Sun, Oct 20, 2019 at 4:43 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:

PG Bug reporting form <noreply@postgresql.org> writes:

Operating system: MacOS

running bootstrap script ... 2019-10-19 23:25:15.095 JST [51410] FATAL:
could not create semaphores: No space left on device
2019-10-19 23:25:15.095 JST [51410] DETAIL: Failed system call was
semget(5432226, 17, 03600).

That's a bit odd. macOS is known to have low default limits for
SysV shared memory, but not for semaphores. Which macOS version
are you running, exactly? What do you get from
sysctl -a | grep sysv.sem
? I get

kern.sysv.semmni: 87381
kern.sysv.semmns: 87381
kern.sysv.semmnu: 87381
kern.sysv.semmsl: 87381
kern.sysv.semume: 10

(and not only in Catalina, but very ancient mac versions)

Is it possible that something else is chewing up semaphores?
Looking at "sudo ipcs -s" output would reveal that.

I have seen a Mac get into that state a couple of times after much
uptime and much hacking and testing, and had to clean them up manually
with ipcrm. Perhaps the occasional kill -9 (don't try this at home)
or postmaster crash, with some bad luck I guess IpcSemaphoreCreate()
could be fooled by a PID that has been recycled, and decide not to
recycle the sema? I don't think it's anything to do with macOS
really, just the fact that we don't use SysV flavoured semaphores
elsewhere and even then most people don't do weird things to their
PostgreSQL clusters like pgsql-hackers denizens...