Re: BUG #16067: Failed system call was semget

On Sun, Oct 20, 2019 at 4:43 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> PG Bug reporting form <noreply(at)postgresql(dot)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...