<listitem>
      <para>
       The parallel regression tests (<literal>make check</literal>)
       can generate spurious regression test failures due to
       overflowing the <function>listen()</function> backlog queue
       which causes connection refused errors or hangs.  You can limit
       the number of connections using the make
       variable <varname>MAX_CONNECTIONS</varname> thus:
<programlisting>
make MAX_CONNECTIONS=5 check
</programlisting>
       (On some systems you can have up to about 10 simultaneous
       connections.)
      </para>
     </listitem>
    </itemizedlist>
   </para>

   <para>
    It is possible to install <command>cygserver</command> and the
    PostgreSQL server as Windows NT services.  For information on how
    to do this, please refer to the <filename>README</filename>
    document included with the PostgreSQL binary package on Cygwin.
    It is installed in the
    directory <filename>/usr/share/doc/Cygwin</filename>.
   </para>
  </sect2>

  <sect2 id="installation-notes-macos">
   <title>macOS</title>

   <indexterm zone="installation-notes-macos">
    <primary>macOS</primary>
    <secondary>installation on</secondary>
   </indexterm>

   <para>
    To build <productname>PostgreSQL</productname> from source
    on <productname>macOS</productname>, you will need to install Apple's
    command line developer tools, which can be done by issuing
<programlisting>
xcode-select --install
</programlisting>
    (note that this will pop up a GUI dialog window for confirmation).
    You may or may not wish to also install Xcode.
   </para>

   <para>
    On recent <productname>macOS</productname> releases, it's necessary to
    embed the <quote>sysroot</quote> path in the include switches used to
    find some system header files.  This results in the outputs of
    the <application>configure</application> script varying depending on
    which SDK version was used during <application>configure</application>.
    That shouldn't pose any problem in simple scenarios, but if you are
    trying to do something like building an extension on a different machine
    than the server code was built on, you may need to force use of a
    different sysroot path.  To do that, set <varname>PG_SYSROOT</varname>,
    for example
<programlisting>
make PG_SYSROOT=<replaceable>/desired/path</replaceable> all
</programlisting>
    To find out the appropriate path on your machine, run
<programlisting>
xcrun --show-sdk-path
</programlisting>
    Note that building an extension using a different sysroot version than
    was used to build the core server is not really recommended; in the
    worst case it could result in hard-to-debug ABI inconsistencies.
   </para>

   <para>
    You can also select a non-default sysroot path when configuring, by
    specifying <varname>PG_SYSROOT</varname>
    to <application>configure</application>:
<programlisting>
./configure ... PG_SYSROOT=<replaceable>/desired/path</replaceable>
</programlisting>
    This would primarily be useful to cross-compile for some other
    macOS version.  There is no guarantee that the resulting executables
    will run on the current host.
   </para>

   <para>
    To suppress the <option>-isysroot</option> options altogether, use
<programlisting>
./configure ... PG_SYSROOT=none
</programlisting>
    (any nonexistent pathname will work).  This might be useful if you wish
    to build with a non-Apple compiler, but beware that that case is not
    tested or supported by the PostgreSQL developers.
   </para>

   <para>
    <productname>macOS</productname>'s <quote>System Integrity
    Protection</quote> (SIP) feature breaks <literal>make check</literal>,
    because it prevents passing the needed setting
    of <literal>DYLD_LIBRARY_PATH</literal> down to the executables being
    tested.  You can work around that by doing <literal>make
    install</literal> before <literal>make check</literal>.
    Most PostgreSQL developers just turn off SIP, though.