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

Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> On 2024-12-16 Mo 12:23 AM, Tom Lane wrote:
>> Yeah. That was more-or-less okay before we invented parallel query,
>> but now there needs to be some headroom. I've thought about adjusting
>> initdb to not allow max_connections less than 25 (can't remember if
>> I actually proposed that on-list though). The other way would be to
>> rearrange parallel_schedule to make the max group size less than 20,
>> but that seems like a lot of effort for little benefit.

> 25 seems perfectly reasonable, these days. The current minimum was set
> nearly 7 years ago.

I poked at this a bit on an OpenBSD installation. The out-of-the-box
value of kern.seminfo.semmns seems to be 60, as Alexander said.
It turns out that we can run under that with max_connections = 20,
but not any higher value, the reason being that the number of
semaphores we need is

MaxConnections +
autovacuum_max_workers + 1 +
max_worker_processes +
max_wal_senders +
NUM_AUXILIARY_PROCS

or 20 + 3 + 1 + 8 + 10 + 6 = 48. We allocate semaphores in groups
of SEMAS_PER_SET (16), plus one for identification purposes,
so with this many semaphores needed we create 3 sets of 17 semaphores
= 51 semaphores. One more requested semaphore would put us up to 68
semaphores which is more than OpenBSD's SEMMNS. So we're already on
the hairy edge here.

Now we could just blow this off and say that we can't run on OpenBSD
at all without an increase in kern.seminfo.semmns. But that seems a
little sad, because there are easy things we could do to make this
less tight:

* Why in the world is the default value of max_wal_senders 10?
I find it hard to believe that there are installations using
more than about 3, and even there you can bet they are changing
a lot of other parameters.

* There's no reason that SEMAS_PER_SET has to be a power of 2. The
commentary in sysv_sema.c says "It must be *less than* your kernel's
SEMMSL (max semaphores per set) parameter, which is often around 25".
If we made it, say, 19, then we could allocate 3 sets (really 20
semaphores) and accommodate up to 57 processes without having
to have an increase in kern.seminfo.semmns.

In short then, I propose:

* Increase initdb's minimum probed max_connections to 25.

* Reduce default value of max_wal_senders to 3 (or maybe 5
if people think that's too drastic).

* Change sysv_sema.c's SEMAS_PER_SET to 19.

On a stock OpenBSD setup, I find that this actually lets
us set max_connections to 30, so that there's some headroom
for the inevitable future growth of the number of background
processes.

Of course, none of this is going to save owners of *BSD
buildfarm animals from needing to increase the kernel
parameters, because the regression tests launch multiple
postmasters in places. But I think it's friendly to novice
PG users if they can launch one postmaster without that.

regards, tom lane