Re: Regression tests fail on OpenBSD due to low semmns value

Peter Eisentraut <peter(at)eisentraut(dot)org> writes:
>>> * Why in the world is the default value of max_wal_senders 10?

> Here is where this change was originally discussed:
> https://www.postgresql.org/message-id/flat/CABUevEy4PR_EAvZEzsbF5s%2BV0eEvw7shJ2t-AUwbHOjT%2ByRb3A%40mail.gmail.com

Hmm. There was not a lot in that thread about which specific nonzero
value of max_wal_senders to use, but I do see

>> After some testing and searching for documentation, it seems that at
>> least the BSD platforms have a very low default semmns setting
>> (apparently 60, which leads to max_connections=30).

> The low semaphore settings on some BSD systems were also mentioned
> there. Did anything change now that it is triggering more issues now?

Yeah, we have more background-process slots reserved by default now.
There's parallel worker slots that were not there in v10, and I think
another one or two random auxiliary processes. So we fail to reach
max_connections=30 now.

As things stand today, we can allocate exactly 20 max_connections
because there are 28 background-process slots if all other parameters
are left at default, and 48 usable semaphores is as many as we
can create under the OpenBSD/NetBSD default of SEMMNS=60. So we're
skating at the hairy edge of whether the parallel regression tests
work reliably, and the next time somebody invents a new kind of
auxiliary process, it will stop working altogether.

My proposal to increase SEMAS_PER_SET to 19 would provide us nine
more usable semaphores under the default *BSD configuration.
With the change to initdb to probe 25 not 20 for max_connections,
five of those would go into max_connections and we'd have four
spares for new background processes. Maybe by the time that runs
out, we'll have found a better alternative to SysV semaphores.

The only downside I can see is that the current setup is able
to coexist with some other service that uses a small number of
SysV semaphores, while with these changes that would not work
without raising the platform SEMMNS limit. Realistically though
you're going to want to raise the platform limit for any sort of
production usage of Postgres. I think this discussion is just
about whether "make; make check" will work out-of-the-box, which
I think is a good goal to have.

regards, tom lane