Re: BUG #16067: Failed system call was semget - Mailing list pgsql-bugs

From Tom Lane
Subject Re: BUG #16067: Failed system call was semget
Date
Msg-id 15052.1571542969@sss.pgh.pa.us
Whole thread Raw
In response to BUG #16067: Failed system call was semget  (PG Bug reporting form <noreply@postgresql.org>)
Responses Re: BUG #16067: Failed system call was semget  (Thomas Munro <thomas.munro@gmail.com>)
List pgsql-bugs
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



pgsql-bugs by date:

Previous
From: Jeff Janes
Date:
Subject: Re: BUG #16065: The operation nodes in query plans outputted byEXPLAIN have no authoritative definitions.
Next
From: Eric Toombs
Date:
Subject: Re: BUG #16065: The operation nodes in query plans outputted byEXPLAIN have no authoritative definitions.