Peter Eisentraut <pe...@eisentraut.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
