Hi,
On 2024-12-18 11:23:23 -0500, Tom Lane wrote:
> Peter Eisentraut <peter@eisentraut.org> writes:
> >> 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.
Maybe we should consider switching those platforms to unnamed posix
semaphores?
There were some not so great performance numbers in the past:
* openbsd, 2021: https://www.postgresql.org/message-id/3010886.1634950831%40sss.pgh.pa.us
* netbsd, 2022: https://www.postgresql.org/message-id/20220828013914.5hzc7kvcpum5h2yn%40awork3.anarazel.de
But TBH, nobody uses openbsd and netbsd if performance matters even one
iota. And considering a bunch of postgres changes to deal with idiotic default
sysv limits doesn't feal like a sensible thing to do in 2024.
Greetings,
Andres Freund
