Hi, On 2024-12-18 11:23:23 -0500, Tom Lane wrote: > Peter Eisentraut <pe...@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
