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-060efcd9954e@gmail.com

1 files changed, 8 insertions, 8 deletions

diff --git a/doc/src/sgml/runtime.sgml b/doc/src/sgml/runtime.sgml
index 94135e9d5ee..8750044852d 100644
--- a/doc/src/sgml/runtime.sgml
+++ b/doc/src/sgml/runtime.sgml
@@ -782,19 +782,19 @@ psql: error: connection to server on socket "/tmp/.s.PGSQL.5432" failed: No such
        <row>
         <entry><varname>SEMMNI</varname></entry>
         <entry>Maximum number of semaphore identifiers (i.e., sets)</entry>
-        <entry>at least <literal>ceil(num_os_semaphores / 16)</literal> plus room for other applications</entry>
+        <entry>at least <literal>ceil(num_os_semaphores / 19)</literal> plus room for other applications</entry>
        </row>
 
        <row>
         <entry><varname>SEMMNS</varname></entry>
         <entry>Maximum number of semaphores system-wide</entry>
-        <entry><literal>ceil(num_os_semaphores / 16) * 17</literal> plus room for other applications</entry>
+        <entry><literal>ceil(num_os_semaphores / 19) * 20</literal> plus room for other applications</entry>
        </row>
 
        <row>
         <entry><varname>SEMMSL</varname></entry>
         <entry>Maximum number of semaphores per set</entry>
-        <entry>at least 17</entry>
+        <entry>at least 20</entry>
        </row>
 
        <row>
@@ -841,7 +841,7 @@ psql: error: connection to server on socket "/tmp/.s.PGSQL.5432" failed: No such
     (<xref linkend="guc-max-connections"/>), allowed autovacuum worker process
     (<xref linkend="guc-autovacuum-max-workers"/>), allowed WAL sender process
     (<xref linkend="guc-max-wal-senders"/>), allowed background
-    process (<xref linkend="guc-max-worker-processes"/>), etc., in sets of 16.
+    process (<xref linkend="guc-max-worker-processes"/>), etc., in sets of 19.
     The runtime-computed parameter <xref linkend="guc-num-os-semaphores"/>
     reports the number of semaphores required.  This parameter can be viewed
     before starting the server with a <command>postgres</command> command like:
@@ -851,17 +851,17 @@ $ <userinput>postgres -D $PGDATA -C num_os_semaphores</userinput>
    </para>
 
    <para>
-    Each set of 16 semaphores will
-    also contain a 17th semaphore which contains a <quote>magic
+    Each set of 19 semaphores will
+    also contain a 20th semaphore which contains a <quote>magic
     number</quote>, to detect collision with semaphore sets used by
     other applications. The maximum number of semaphores in the system
     is set by <varname>SEMMNS</varname>, which consequently must be at least
     as high as <literal>num_os_semaphores</literal> plus one extra for
-    each set of 16 required semaphores (see the formula in <xref
+    each set of 19 required semaphores (see the formula in <xref
     linkend="sysvipc-parameters"/>).  The parameter <varname>SEMMNI</varname>
     determines the limit on the number of semaphore sets that can
     exist on the system at one time.  Hence this parameter must be at
-    least <literal>ceil(num_os_semaphores / 16)</literal>.
+    least <literal>ceil(num_os_semaphores / 19)</literal>.
     Lowering the number
     of allowed connections is a temporary workaround for failures,
     which are usually confusingly worded <quote>No space