Try to avoid semaphore-related test failures on NetBSD/OpenBSD. These two platforms have a remarkably tight default limit on the number of SysV semaphores in the system: SEMMNS is only 60 out-of-the-box. Unless manual action is taken to raise that, we'll only be able to allocate 3 sets of 16 usable semaphores each, leading to initdb setting max_connections to just 20. That's problematic because the core regression tests expect to be able to launch 20 concurrent sessions, leaving us with no headroom. This seems to be the cause of intermittent buildfarm failures on some machines.
While there's no getting around the fact that you'd better raise SEMMNS for production use on these platforms, it does seem desirable for "make check" to pass reliably without that. We can make that happen, at least for awhile longer, with two small changes: * Change sysv_sema.c's SEMAS_PER_SET to 19, so that we can eat up all of the available semas not just most of them. * Change initdb to make the smallest max_connections value it will consider be 25 not 20. As of HEAD this will leave us with four free semaphores (using the default values for other relevant parameters such as max_wal_senders). So we won't need to consider this again until we've invented five more background processes. Maybe by then we can switch both these platforms to some other semaphore API. For the moment, do this only in master; there've not been field complaints that might justify a back-patch. Discussion: https://postgr.es/m/db2773a2-aca0-43d0-99c1-060efcd99...@gmail.com Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/38da053463bef32adf563ddee5277d16d2b6c5af Modified Files -------------- doc/src/sgml/runtime.sgml | 16 ++++++++-------- src/backend/port/sysv_sema.c | 8 +++++++- src/bin/initdb/initdb.c | 2 +- 3 files changed, 16 insertions(+), 10 deletions(-)
