Hi,
On 2024-12-16 12:52:46 -0500, Tom Lane wrote:
> 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.
Given the numbers of users (or even testers) on openbsd that seems like it
might be a reasonable answer... But, see below.
> * 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.
I don't think it's that rare as logical replication also needs a walsender
slot... I think we're going to hurt far more users by lowering this than we'd
help.
But I think it might be sane to have initdb probe a lower max_wal_senders
alongside lower max_connections settings. It seems to make sense to have a
lower max_wal_senders settings on machines that don't have enough resources to
run with max_connections=100.
Greetings,
Andres Freund