Adding upstream version 15.5.upstream/15.5

Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>

1 files changed, 1572 insertions, 0 deletions

diff --git a/INSTALL b/INSTALL
new file mode 100644
index 0000000..f26d19c
--- /dev/null
+++ b/INSTALL
@@ -0,0 +1,1572 @@
+PostgreSQL Installation from Source Code
+
+------------------------------------------------------------------------
+
+This document describes the installation of PostgreSQL using this source
+code distribution.
+
+If you are building PostgreSQL for Microsoft Windows, read this document
+if you intend to build with MinGW or Cygwin; but if you intend to build
+with Microsoft's Visual C++, see the main documentation instead.
+
+------------------------------------------------------------------------
+
+Short Version
+
+    ./configure
+    make
+    su
+    make install
+    adduser postgres
+    mkdir -p /usr/local/pgsql/data
+    chown postgres /usr/local/pgsql/data
+    su - postgres
+    /usr/local/pgsql/bin/initdb -D /usr/local/pgsql/data
+    /usr/local/pgsql/bin/pg_ctl -D /usr/local/pgsql/data -l logfile start
+    /usr/local/pgsql/bin/createdb test
+    /usr/local/pgsql/bin/psql test
+
+The long version is the rest of this document.
+
+------------------------------------------------------------------------
+
+Requirements
+
+In general, a modern Unix-compatible platform should be able to run
+PostgreSQL. The platforms that had received specific testing at the time
+of release are described in the section called "Supported Platforms"
+below.
+
+The following software packages are required for building PostgreSQL:
+
+-   GNU make version 3.81 or newer is required; other make programs or
+    older GNU make versions will *not* work. (GNU make is sometimes
+    installed under the name "gmake".) To test for GNU make enter:
+
+        make --version
+
+-   You need an ISO/ANSI C compiler (at least C99-compliant). Recent
+    versions of GCC are recommended, but PostgreSQL is known to build
+    using a wide variety of compilers from different vendors.
+
+-   tar is required to unpack the source distribution, in addition to
+    either gzip or bzip2.
+
+-   The GNU Readline library is used by default. It allows psql (the
+    PostgreSQL command line SQL interpreter) to remember each command
+    you type, and allows you to use arrow keys to recall and edit
+    previous commands. This is very helpful and is strongly recommended.
+    If you don't want to use it then you must specify the
+    "--without-readline" option to "configure". As an alternative, you
+    can often use the BSD-licensed "libedit" library, originally
+    developed on NetBSD. The "libedit" library is GNU
+    Readline-compatible and is used if "libreadline" is not found, or if
+    "--with-libedit-preferred" is used as an option to "configure". If
+    you are using a package-based Linux distribution, be aware that you
+    need both the readline and readline-devel packages, if those are
+    separate in your distribution.
+
+-   The zlib compression library is used by default. If you don't want
+    to use it then you must specify the "--without-zlib" option to
+    "configure". Using this option disables support for compressed
+    archives in pg_dump and pg_restore.
+
+The following packages are optional. They are not required in the
+default configuration, but they are needed when certain build options
+are enabled, as explained below:
+
+-   To build the server programming language PL/Perl you need a full
+    Perl installation, including the "libperl" library and the header
+    files. The minimum required version is Perl 5.8.3. Since PL/Perl
+    will be a shared library, the "libperl" library must be a shared
+    library also on most platforms. This appears to be the default in
+    recent Perl versions, but it was not in earlier versions, and in any
+    case it is the choice of whomever installed Perl at your site.
+    "configure" will fail if building PL/Perl is selected but it cannot
+    find a shared "libperl". In that case, you will have to rebuild and
+    install Perl manually to be able to build PL/Perl. During the
+    configuration process for Perl, request a shared library.
+
+    If you intend to make more than incidental use of PL/Perl, you
+    should ensure that the Perl installation was built with the
+    usemultiplicity option enabled (perl -V will show whether this is
+    the case).
+
+-   To build the PL/Python server programming language, you need a
+    Python installation with the header files and the sysconfig module.
+    The minimum required version is Python 3.2.
+
+    Since PL/Python will be a shared library, the "libpython" library
+    must be a shared library also on most platforms. This is not the
+    case in a default Python installation built from source, but a
+    shared library is available in many operating system distributions.
+    "configure" will fail if building PL/Python is selected but it
+    cannot find a shared "libpython". That might mean that you either
+    have to install additional packages or rebuild (part of) your Python
+    installation to provide this shared library. When building from
+    source, run Python's configure with the --enable-shared flag.
+
+-   To build the PL/Tcl procedural language, you of course need a Tcl
+    installation. The minimum required version is Tcl 8.4.
+
+-   To enable Native Language Support (NLS), that is, the ability to
+    display a program's messages in a language other than English, you
+    need an implementation of the Gettext API. Some operating systems
+    have this built-in (e.g., Linux, NetBSD, Solaris), for other systems
+    you can download an add-on package from
+    https://www.gnu.org/software/gettext/. If you are using the Gettext
+    implementation in the GNU C library then you will additionally need
+    the GNU Gettext package for some utility programs. For any of the
+    other implementations you will not need it.
+
+-   You need OpenSSL, if you want to support encrypted client
+    connections. OpenSSL is also required for random number generation
+    on platforms that do not have "/dev/urandom" (except Windows). The
+    minimum required version is 1.0.1.
+
+-   You need Kerberos, OpenLDAP, and/or PAM, if you want to support
+    authentication using those services.
+
+-   You need LZ4, if you want to support compression of data with that
+    method; see the configuration parameter default_toast_compression
+    and the configuration parameter wal_compression.
+
+-   You need Zstandard, if you want to support compression of data with
+    that method; see the configuration parameter wal_compression. The
+    minimum required version is 1.4.0.
+
+-   To build the PostgreSQL documentation, there is a separate set of
+    requirements; see the main documentation's appendix on
+    documentation.
+
+If you are building from a Git tree instead of using a released source
+package, or if you want to do server development, you also need the
+following packages:
+
+-   Flex and Bison are needed to build from a Git checkout, or if you
+    changed the actual scanner and parser definition files. If you need
+    them, be sure to get Flex 2.5.31 or later and Bison 1.875 or later.
+    Other lex and yacc programs cannot be used.
+
+-   Perl 5.8.3 or later is needed to build from a Git checkout, or if
+    you changed the input files for any of the build steps that use Perl
+    scripts. If building on Windows you will need Perl in any case. Perl
+    is also required to run some test suites.
+
+If you need to get a GNU package, you can find it at your local GNU
+mirror site (see https://www.gnu.org/prep/ftp for a list) or at
+ftp://ftp.gnu.org/gnu/.
+
+Also check that you have sufficient disk space. You will need about 350
+MB for the source tree during compilation and about 60 MB for the
+installation directory. An empty database cluster takes about 40 MB;
+databases take about five times the amount of space that a flat text
+file with the same data would take. If you are going to run the
+regression tests you will temporarily need up to an extra 300 MB. Use
+the "df" command to check free disk space.
+
+------------------------------------------------------------------------
+
+Installation Procedure
+
+1.  Configuration
+
+    The first step of the installation procedure is to configure the
+    source tree for your system and choose the options you would like.
+    This is done by running the "configure" script. For a default
+    installation simply enter:
+
+        ./configure
+
+    This script will run a number of tests to determine values for
+    various system dependent variables and detect any quirks of your
+    operating system, and finally will create several files in the build
+    tree to record what it found.
+
+    You can also run "configure" in a directory outside the source tree,
+    and then build there, if you want to keep the build directory
+    separate from the original source files. This procedure is called a
+    VPATH build. Here's how:
+
+        mkdir build_dir
+        cd build_dir
+        /path/to/source/tree/configure [options go here]
+        make
+
+    The default configuration will build the server and utilities, as
+    well as all client applications and interfaces that require only a C
+    compiler. All files will be installed under "/usr/local/pgsql" by
+    default.
+
+    You can customize the build and installation process by supplying
+    one or more command line options to "configure". Typically you would
+    customize the install location, or the set of optional features that
+    are built. "configure" has a large number of options, which are
+    described in the section called "configure Options".
+
+    Also, "configure" responds to certain environment variables, as
+    described in the section called "configure Environment Variables".
+    These provide additional ways to customize the configuration.
+
+2.  Build
+
+    To start the build, type either of:
+
+        make
+        make all
+
+    (Remember to use GNU make.) The build will take a few minutes
+    depending on your hardware.
+
+    If you want to build everything that can be built, including the
+    documentation (HTML and man pages), and the additional modules
+    ("contrib"), type instead:
+
+        make world
+
+    If you want to build everything that can be built, including the
+    additional modules ("contrib"), but without the documentation, type
+    instead:
+
+        make world-bin
+
+    If you want to invoke the build from another makefile rather than
+    manually, you must unset MAKELEVEL or set it to zero, for instance
+    like this:
+
+        build-postgresql:
+                $(MAKE) -C postgresql MAKELEVEL=0 all
+
+    Failure to do that can lead to strange error messages, typically
+    about missing header files.
+
+3.  Regression Tests
+
+    If you want to test the newly built server before you install it,
+    you can run the regression tests at this point. The regression tests
+    are a test suite to verify that PostgreSQL runs on your machine in
+    the way the developers expected it to. Type:
+
+        make check
+
+    (This won't work as root; do it as an unprivileged user.) See the
+    file "src/test/regress/README" and the documentation for detailed
+    information about interpreting the test results. You can repeat this
+    test at any later time by issuing the same command.
+
+4.  Installing the Files
+
+    Note:
+
+    If you are upgrading an existing system be sure to read the
+    documentation, which has instructions about upgrading a cluster.
+
+    To install PostgreSQL enter:
+
+        make install
+
+    This will install files into the directories that were specified in
+    Step 1. Make sure that you have appropriate permissions to write
+    into that area. Normally you need to do this step as root.
+    Alternatively, you can create the target directories in advance and
+    arrange for appropriate permissions to be granted.
+
+    To install the documentation (HTML and man pages), enter:
+
+        make install-docs
+
+    If you built the world above, type instead:
+
+        make install-world
+
+    This also installs the documentation.
+
+    If you built the world without the documentation above, type
+    instead:
+
+        make install-world-bin
+
+    You can use make install-strip instead of make install to strip the
+    executable files and libraries as they are installed. This will save
+    some space. If you built with debugging support, stripping will
+    effectively remove the debugging support, so it should only be done
+    if debugging is no longer needed. install-strip tries to do a
+    reasonable job saving space, but it does not have perfect knowledge
+    of how to strip every unneeded byte from an executable file, so if
+    you want to save all the disk space you possibly can, you will have
+    to do manual work.
+
+    The standard installation provides all the header files needed for
+    client application development as well as for server-side program
+    development, such as custom functions or data types written in C.
+
+    Client-only installation:  If you want to install only the client
+    applications and interface libraries, then you can use these
+    commands:
+
+        make -C src/bin install
+        make -C src/include install
+        make -C src/interfaces install
+        make -C doc install
+
+    "src/bin" has a few binaries for server-only use, but they are
+    small.
+
+Uninstallation:  To undo the installation use the command "make
+uninstall". However, this will not remove any created directories.
+
+Cleaning:  After the installation you can free disk space by removing
+the built files from the source tree with the command "make clean". This
+will preserve the files made by the "configure" program, so that you can
+rebuild everything with "make" later on. To reset the source tree to the
+state in which it was distributed, use "make distclean". If you are
+going to build for several platforms within the same source tree you
+must do this and re-configure for each platform. (Alternatively, use a
+separate build tree for each platform, so that the source tree remains
+unmodified.)
+
+If you perform a build and then discover that your "configure" options
+were wrong, or if you change anything that "configure" investigates (for
+example, software upgrades), then it's a good idea to do "make
+distclean" before reconfiguring and rebuilding. Without this, your
+changes in configuration choices might not propagate everywhere they
+need to.
+
+------------------------------------------------------------------------
+
+configure Options
+
+"configure"'s command line options are explained below. This list is not
+exhaustive (use ./configure --help to get one that is). The options not
+covered here are meant for advanced use-cases such as cross-compilation,
+and are documented in the standard Autoconf documentation.
+
+------------------------------------------------------------------------
+
+Installation Locations
+
+These options control where make install will put the files. The
+"--prefix" option is sufficient for most cases. If you have special
+needs, you can customize the installation subdirectories with the other
+options described in this section. Beware however that changing the
+relative locations of the different subdirectories may render the
+installation non-relocatable, meaning you won't be able to move it after
+installation. (The man and doc locations are not affected by this
+restriction.) For relocatable installs, you might want to use the
+--disable-rpath option described later.
+
+--prefix=PREFIX
+
+    Install all files under the directory "PREFIX" instead of
+    "/usr/local/pgsql". The actual files will be installed into various
+    subdirectories; no files will ever be installed directly into the
+    "PREFIX" directory.
+
+--exec-prefix=EXEC-PREFIX
+
+    You can install architecture-dependent files under a different
+    prefix, "EXEC-PREFIX", than what "PREFIX" was set to. This can be
+    useful to share architecture-independent files between hosts. If you
+    omit this, then "EXEC-PREFIX" is set equal to "PREFIX" and both
+    architecture-dependent and independent files will be installed under
+    the same tree, which is probably what you want.
+
+--bindir=DIRECTORY
+
+    Specifies the directory for executable programs. The default is
+    "EXEC-PREFIX/bin", which normally means "/usr/local/pgsql/bin".
+
+--sysconfdir=DIRECTORY
+
+    Sets the directory for various configuration files, "PREFIX/etc" by
+    default.
+
+--libdir=DIRECTORY
+
+    Sets the location to install libraries and dynamically loadable
+    modules. The default is "EXEC-PREFIX/lib".
+
+--includedir=DIRECTORY
+
+    Sets the directory for installing C and C++ header files. The
+    default is "PREFIX/include".
+
+--datarootdir=DIRECTORY
+
+    Sets the root directory for various types of read-only data files.
+    This only sets the default for some of the following options. The
+    default is "PREFIX/share".
+
+--datadir=DIRECTORY
+
+    Sets the directory for read-only data files used by the installed
+    programs. The default is "DATAROOTDIR". Note that this has nothing
+    to do with where your database files will be placed.
+
+--localedir=DIRECTORY
+
+    Sets the directory for installing locale data, in particular message
+    translation catalog files. The default is "DATAROOTDIR/locale".
+
+--mandir=DIRECTORY
+
+    The man pages that come with PostgreSQL will be installed under this
+    directory, in their respective "manx" subdirectories. The default is
+    "DATAROOTDIR/man".
+
+--docdir=DIRECTORY
+
+    Sets the root directory for installing documentation files, except
+    "man" pages. This only sets the default for the following options.
+    The default value for this option is "DATAROOTDIR/doc/postgresql".
+
+--htmldir=DIRECTORY
+
+    The HTML-formatted documentation for PostgreSQL will be installed
+    under this directory. The default is "DATAROOTDIR".
+
+Note:
+
+Care has been taken to make it possible to install PostgreSQL into
+shared installation locations (such as "/usr/local/include") without
+interfering with the namespace of the rest of the system. First, the
+string "/postgresql" is automatically appended to datadir, sysconfdir,
+and docdir, unless the fully expanded directory name already contains
+the string "postgres" or "pgsql". For example, if you choose
+"/usr/local" as prefix, the documentation will be installed in
+"/usr/local/doc/postgresql", but if the prefix is "/opt/postgres", then
+it will be in "/opt/postgres/doc". The public C header files of the
+client interfaces are installed into includedir and are namespace-clean.
+The internal header files and the server header files are installed into
+private directories under includedir. See the documentation of each
+interface for information about how to access its header files. Finally,
+a private subdirectory will also be created, if appropriate, under
+libdir for dynamically loadable modules.
+
+------------------------------------------------------------------------
+
+PostgreSQL Features
+
+The options described in this section enable building of various
+PostgreSQL features that are not built by default. Most of these are
+non-default only because they require additional software, as described
+in the section called "Requirements".
+
+--enable-nls[=LANGUAGES]
+
+    Enables Native Language Support (NLS), that is, the ability to
+    display a program's messages in a language other than English.
+    "LANGUAGES" is an optional space-separated list of codes of the
+    languages that you want supported, for example --enable-nls='de fr'.
+    (The intersection between your list and the set of actually provided
+    translations will be computed automatically.) If you do not specify
+    a list, then all available translations are installed.
+
+    To use this option, you will need an implementation of the Gettext
+    API.
+
+--with-perl
+
+    Build the PL/Perl server-side language.
+
+--with-python
+
+    Build the PL/Python server-side language.
+
+--with-tcl
+
+    Build the PL/Tcl server-side language.
+
+--with-tclconfig=DIRECTORY
+
+    Tcl installs the file "tclConfig.sh", which contains configuration
+    information needed to build modules interfacing to Tcl. This file is
+    normally found automatically at a well-known location, but if you
+    want to use a different version of Tcl you can specify the directory
+    in which to look for "tclConfig.sh".
+
+--with-icu
+
+    Build with support for the ICU library, enabling use of ICU
+    collation features. This requires the ICU4C package to be installed.
+    The minimum required version of ICU4C is currently 4.2.
+
+    By default, pkg-config will be used to find the required compilation
+    options. This is supported for ICU4C version 4.6 and later. For
+    older versions, or if pkg-config is not available, the variables
+    ICU_CFLAGS and ICU_LIBS can be specified to "configure", like in
+    this example:
+
+        ./configure ... --with-icu ICU_CFLAGS='-I/some/where/include' ICU_LIBS='-L/some/where/lib -licui18n -licuuc -licudata'
+
+    (If ICU4C is in the default search path for the compiler, then you
+    still need to specify nonempty strings in order to avoid use of
+    pkg-config, for example, ICU_CFLAGS=' '.)
+
+--with-llvm
+
+    Build with support for LLVM based JIT compilation. This requires the
+    LLVM library to be installed. The minimum required version of LLVM
+    is currently 3.9.
+
+    "llvm-config" will be used to find the required compilation options.
+    "llvm-config", and then "llvm-config-$major-$minor" for all
+    supported versions, will be searched for in your PATH. If that would
+    not yield the desired program, use LLVM_CONFIG to specify a path to
+    the correct "llvm-config". For example
+
+        ./configure ... --with-llvm LLVM_CONFIG='/path/to/llvm/bin/llvm-config'
+
+    LLVM support requires a compatible "clang" compiler (specified, if
+    necessary, using the CLANG environment variable), and a working C++
+    compiler (specified, if necessary, using the CXX environment
+    variable).
+
+--with-lz4
+
+    Build with LZ4 compression support.
+
+--with-zstd
+
+    Build with Zstandard compression support.
+
+--with-ssl=LIBRARY 
+
+    Build with support for SSL (encrypted) connections. The only
+    "LIBRARY" supported is "openssl". This requires the OpenSSL package
+    to be installed. "configure" will check for the required header
+    files and libraries to make sure that your OpenSSL installation is
+    sufficient before proceeding.
+
+--with-openssl
+
+    Obsolete equivalent of --with-ssl=openssl.
+
+--with-gssapi
+
+    Build with support for GSSAPI authentication. On many systems, the
+    GSSAPI system (usually a part of the Kerberos installation) is not
+    installed in a location that is searched by default (e.g.,
+    "/usr/include", "/usr/lib"), so you must use the options
+    "--with-includes" and "--with-libraries" in addition to this option.
+    "configure" will check for the required header files and libraries
+    to make sure that your GSSAPI installation is sufficient before
+    proceeding.
+
+--with-ldap
+
+    Build with LDAP support for authentication and connection parameter
+    lookup (see the documentation about client authentication and libpq
+    for more information). On Unix, this requires the OpenLDAP package
+    to be installed. On Windows, the default WinLDAP library is used.
+    "configure" will check for the required header files and libraries
+    to make sure that your OpenLDAP installation is sufficient before
+    proceeding.
+
+--with-pam
+
+    Build with PAM (Pluggable Authentication Modules) support.
+
+--with-bsd-auth
+
+    Build with BSD Authentication support. (The BSD Authentication
+    framework is currently only available on OpenBSD.)
+
+--with-systemd
+
+    Build with support for systemd service notifications. This improves
+    integration if the server is started under systemd but has no impact
+    otherwise. libsystemd and the associated header files need to be
+    installed to use this option.
+
+--with-bonjour
+
+    Build with support for Bonjour automatic service discovery. This
+    requires Bonjour support in your operating system. Recommended on
+    macOS.
+
+--with-uuid=LIBRARY
+
+    Build the uuid-ossp module (which provides functions to generate
+    UUIDs), using the specified UUID library. "LIBRARY" must be one of:
+
+    -   "bsd" to use the UUID functions found in FreeBSD and some other
+        BSD-derived systems
+
+    -   "e2fs" to use the UUID library created by the e2fsprogs project;
+        this library is present in most Linux systems and in macOS, and
+        can be obtained for other platforms as well
+
+    -   "ossp" to use the OSSP UUID library
+
+--with-ossp-uuid
+
+    Obsolete equivalent of --with-uuid=ossp.
+
+--with-libxml
+
+    Build with libxml2, enabling SQL/XML support. Libxml2 version 2.6.23
+    or later is required for this feature.
+
+    To detect the required compiler and linker options, PostgreSQL will
+    query "pkg-config", if that is installed and knows about libxml2.
+    Otherwise the program "xml2-config", which is installed by libxml2,
+    will be used if it is found. Use of "pkg-config" is preferred,
+    because it can deal with multi-architecture installations better.
+
+    To use a libxml2 installation that is in an unusual location, you
+    can set "pkg-config"-related environment variables (see its
+    documentation), or set the environment variable XML2_CONFIG to point
+    to the "xml2-config" program belonging to the libxml2 installation,
+    or set the variables XML2_CFLAGS and XML2_LIBS. (If "pkg-config" is
+    installed, then to override its idea of where libxml2 is you must
+    either set XML2_CONFIG or set both XML2_CFLAGS and XML2_LIBS to
+    nonempty strings.)
+
+--with-libxslt
+
+    Build with libxslt, enabling the xml2 module to perform XSL
+    transformations of XML. "--with-libxml" must be specified as well.
+
+------------------------------------------------------------------------
+
+Anti-Features
+
+The options described in this section allow disabling certain PostgreSQL
+features that are built by default, but which might need to be turned
+off if the required software or system features are not available. Using
+these options is not recommended unless really necessary.
+
+--without-readline
+
+    Prevents use of the Readline library (and libedit as well). This
+    option disables command-line editing and history in psql.
+
+--with-libedit-preferred
+
+    Favors the use of the BSD-licensed libedit library rather than
+    GPL-licensed Readline. This option is significant only if you have
+    both libraries installed; the default in that case is to use
+    Readline.
+
+--without-zlib
+
+    Prevents use of the Zlib library. This disables support for
+    compressed archives in pg_dump and pg_restore.
+
+--disable-spinlocks
+
+    Allow the build to succeed even if PostgreSQL has no CPU spinlock
+    support for the platform. The lack of spinlock support will result
+    in very poor performance; therefore, this option should only be used
+    if the build aborts and informs you that the platform lacks spinlock
+    support. If this option is required to build PostgreSQL on your
+    platform, please report the problem to the PostgreSQL developers.
+
+--disable-atomics
+
+    Disable use of CPU atomic operations. This option does nothing on
+    platforms that lack such operations. On platforms that do have them,
+    this will result in poor performance. This option is only useful for
+    debugging or making performance comparisons.
+
+--disable-thread-safety
+
+    Disable the thread-safety of client libraries. This prevents
+    concurrent threads in libpq and ECPG programs from safely
+    controlling their private connection handles. Use this only on
+    platforms with deficient threading support.
+
+------------------------------------------------------------------------
+
+Build Process Details
+
+--with-includes=DIRECTORIES
+
+    "DIRECTORIES" is a colon-separated list of directories that will be
+    added to the list the compiler searches for header files. If you
+    have optional packages (such as GNU Readline) installed in a
+    non-standard location, you have to use this option and probably also
+    the corresponding "--with-libraries" option.
+
+    Example: --with-includes=/opt/gnu/include:/usr/sup/include.
+
+--with-libraries=DIRECTORIES
+
+    "DIRECTORIES" is a colon-separated list of directories to search for
+    libraries. You will probably have to use this option (and the
+    corresponding "--with-includes" option) if you have packages
+    installed in non-standard locations.
+
+    Example: --with-libraries=/opt/gnu/lib:/usr/sup/lib.
+
+--with-system-tzdata=DIRECTORY 
+
+    PostgreSQL includes its own time zone database, which it requires
+    for date and time operations. This time zone database is in fact
+    compatible with the IANA time zone database provided by many
+    operating systems such as FreeBSD, Linux, and Solaris, so it would
+    be redundant to install it again. When this option is used, the
+    system-supplied time zone database in "DIRECTORY" is used instead of
+    the one included in the PostgreSQL source distribution. "DIRECTORY"
+    must be specified as an absolute path. "/usr/share/zoneinfo" is a
+    likely directory on some operating systems. Note that the
+    installation routine will not detect mismatching or erroneous time
+    zone data. If you use this option, you are advised to run the
+    regression tests to verify that the time zone data you have pointed
+    to works correctly with PostgreSQL.
+
+    This option is mainly aimed at binary package distributors who know
+    their target operating system well. The main advantage of using this
+    option is that the PostgreSQL package won't need to be upgraded
+    whenever any of the many local daylight-saving time rules change.
+    Another advantage is that PostgreSQL can be cross-compiled more
+    straightforwardly if the time zone database files do not need to be
+    built during the installation.
+
+--with-extra-version=STRING
+
+    Append "STRING" to the PostgreSQL version number. You can use this,
+    for example, to mark binaries built from unreleased Git snapshots or
+    containing custom patches with an extra version string, such as a
+    "git describe" identifier or a distribution package release number.
+
+--disable-rpath
+
+    Do not mark PostgreSQL's executables to indicate that they should
+    search for shared libraries in the installation's library directory
+    (see "--libdir"). On most platforms, this marking uses an absolute
+    path to the library directory, so that it will be unhelpful if you
+    relocate the installation later. However, you will then need to
+    provide some other way for the executables to find the shared
+    libraries. Typically this requires configuring the operating
+    system's dynamic linker to search the library directory; see the
+    section called "Shared Libraries" for more detail.
+
+------------------------------------------------------------------------
+
+Miscellaneous
+
+It's fairly common, particularly for test builds, to adjust the default
+port number with "--with-pgport". The other options in this section are
+recommended only for advanced users.
+
+--with-pgport=NUMBER
+
+    Set "NUMBER" as the default port number for server and clients. The
+    default is 5432. The port can always be changed later on, but if you
+    specify it here then both server and clients will have the same
+    default compiled in, which can be very convenient. Usually the only
+    good reason to select a non-default value is if you intend to run
+    multiple PostgreSQL servers on the same machine.
+
+--with-krb-srvnam=NAME
+
+    The default name of the Kerberos service principal used by GSSAPI.
+    postgres is the default. There's usually no reason to change this
+    unless you are building for a Windows environment, in which case it
+    must be set to upper case POSTGRES.
+
+--with-segsize=SEGSIZE
+
+    Set the segment size, in gigabytes. Large tables are divided into
+    multiple operating-system files, each of size equal to the segment
+    size. This avoids problems with file size limits that exist on many
+    platforms. The default segment size, 1 gigabyte, is safe on all
+    supported platforms. If your operating system has "largefile"
+    support (which most do, nowadays), you can use a larger segment
+    size. This can be helpful to reduce the number of file descriptors
+    consumed when working with very large tables. But be careful not to
+    select a value larger than is supported by your platform and the
+    file systems you intend to use. Other tools you might wish to use,
+    such as tar, could also set limits on the usable file size. It is
+    recommended, though not absolutely required, that this value be a
+    power of 2. Note that changing this value breaks on-disk database
+    compatibility, meaning you cannot use "pg_upgrade" to upgrade to a
+    build with a different segment size.
+
+--with-blocksize=BLOCKSIZE
+
+    Set the block size, in kilobytes. This is the unit of storage and
+    I/O within tables. The default, 8 kilobytes, is suitable for most
+    situations; but other values may be useful in special cases. The
+    value must be a power of 2 between 1 and 32 (kilobytes). Note that
+    changing this value breaks on-disk database compatibility, meaning
+    you cannot use "pg_upgrade" to upgrade to a build with a different
+    block size.
+
+--with-wal-blocksize=BLOCKSIZE
+
+    Set the WAL block size, in kilobytes. This is the unit of storage
+    and I/O within the WAL log. The default, 8 kilobytes, is suitable
+    for most situations; but other values may be useful in special
+    cases. The value must be a power of 2 between 1 and 64 (kilobytes).
+    Note that changing this value breaks on-disk database compatibility,
+    meaning you cannot use "pg_upgrade" to upgrade to a build with a
+    different WAL block size.
+
+------------------------------------------------------------------------
+
+Developer Options
+
+Most of the options in this section are only of interest for developing
+or debugging PostgreSQL. They are not recommended for production builds,
+except for "--enable-debug", which can be useful to enable detailed bug
+reports in the unlucky event that you encounter a bug. On platforms
+supporting DTrace, "--enable-dtrace" may also be reasonable to use in
+production.
+
+When building an installation that will be used to develop code inside
+the server, it is recommended to use at least the options
+"--enable-debug" and "--enable-cassert".
+
+--enable-debug
+
+    Compiles all programs and libraries with debugging symbols. This
+    means that you can run the programs in a debugger to analyze
+    problems. This enlarges the size of the installed executables
+    considerably, and on non-GCC compilers it usually also disables
+    compiler optimization, causing slowdowns. However, having the
+    symbols available is extremely helpful for dealing with any problems
+    that might arise. Currently, this option is recommended for
+    production installations only if you use GCC. But you should always
+    have it on if you are doing development work or running a beta
+    version.
+
+--enable-cassert
+
+    Enables assertion checks in the server, which test for many "cannot
+    happen" conditions. This is invaluable for code development
+    purposes, but the tests can slow down the server significantly.
+    Also, having the tests turned on won't necessarily enhance the
+    stability of your server! The assertion checks are not categorized
+    for severity, and so what might be a relatively harmless bug will
+    still lead to server restarts if it triggers an assertion failure.
+    This option is not recommended for production use, but you should
+    have it on for development work or when running a beta version.
+
+--enable-tap-tests
+
+    Enable tests using the Perl TAP tools. This requires a Perl
+    installation and the Perl module IPC::Run.
+
+--enable-depend
+
+    Enables automatic dependency tracking. With this option, the
+    makefiles are set up so that all affected object files will be
+    rebuilt when any header file is changed. This is useful if you are
+    doing development work, but is just wasted overhead if you intend
+    only to compile once and install. At present, this option only works
+    with GCC.
+
+--enable-coverage
+
+    If using GCC, all programs and libraries are compiled with code
+    coverage testing instrumentation. When run, they generate files in
+    the build directory with code coverage metrics. This option is for
+    use only with GCC and when doing development work.
+
+--enable-profiling
+
+    If using GCC, all programs and libraries are compiled so they can be
+    profiled. On backend exit, a subdirectory will be created that
+    contains the "gmon.out" file containing profile data. This option is
+    for use only with GCC and when doing development work.
+
+--enable-dtrace
+
+    Compiles PostgreSQL with support for the dynamic tracing tool
+    DTrace.
+
+    To point to the "dtrace" program, the environment variable DTRACE
+    can be set. This will often be necessary because "dtrace" is
+    typically installed under "/usr/sbin", which might not be in your
+    PATH.
+
+    Extra command-line options for the "dtrace" program can be specified
+    in the environment variable DTRACEFLAGS. On Solaris, to include
+    DTrace support in a 64-bit binary, you must specify
+    DTRACEFLAGS="-64". For example, using the GCC compiler:
+
+        ./configure CC='gcc -m64' --enable-dtrace DTRACEFLAGS='-64' ...
+
+    Using Sun's compiler:
+
+        ./configure CC='/opt/SUNWspro/bin/cc -xtarget=native64' --enable-dtrace DTRACEFLAGS='-64' ...
+
+------------------------------------------------------------------------
+
+configure Environment Variables
+
+In addition to the ordinary command-line options described above,
+"configure" responds to a number of environment variables. You can
+specify environment variables on the "configure" command line, for
+example:
+
+    ./configure CC=/opt/bin/gcc CFLAGS='-O2 -pipe'
+
+In this usage an environment variable is little different from a
+command-line option. You can also set such variables beforehand:
+
+    export CC=/opt/bin/gcc
+    export CFLAGS='-O2 -pipe'
+    ./configure
+
+This usage can be convenient because many programs' configuration
+scripts respond to these variables in similar ways.
+
+The most commonly used of these environment variables are CC and CFLAGS.
+If you prefer a C compiler different from the one "configure" picks, you
+can set the variable CC to the program of your choice. By default,
+"configure" will pick "gcc" if available, else the platform's default
+(usually "cc"). Similarly, you can override the default compiler flags
+if needed with the CFLAGS variable.
+
+Here is a list of the significant variables that can be set in this
+manner:
+
+BISON
+
+    Bison program
+
+CC
+
+    C compiler
+
+CFLAGS
+
+    options to pass to the C compiler
+
+CLANG
+
+    path to "clang" program used to process source code for inlining
+    when compiling with --with-llvm
+
+CPP
+
+    C preprocessor
+
+CPPFLAGS
+
+    options to pass to the C preprocessor
+
+CXX
+
+    C++ compiler
+
+CXXFLAGS
+
+    options to pass to the C++ compiler
+
+DTRACE
+
+    location of the "dtrace" program
+
+DTRACEFLAGS
+
+    options to pass to the "dtrace" program
+
+FLEX
+
+    Flex program
+
+LDFLAGS
+
+    options to use when linking either executables or shared libraries
+
+LDFLAGS_EX
+
+    additional options for linking executables only
+
+LDFLAGS_SL
+
+    additional options for linking shared libraries only
+
+LLVM_CONFIG
+
+    "llvm-config" program used to locate the LLVM installation
+
+MSGFMT
+
+    "msgfmt" program for native language support
+
+PERL
+
+    Perl interpreter program. This will be used to determine the
+    dependencies for building PL/Perl. The default is "perl".
+
+PYTHON
+
+    Python interpreter program. This will be used to determine the
+    dependencies for building PL/Python. If this is not set, the
+    following are probed in this order: python3 python.
+
+TCLSH
+
+    Tcl interpreter program. This will be used to determine the
+    dependencies for building PL/Tcl. If this is not set, the following
+    are probed in this order:
+    tclsh tcl tclsh8.6 tclsh86 tclsh8.5 tclsh85          tclsh8.4 tclsh84.
+
+XML2_CONFIG
+
+    "xml2-config" program used to locate the libxml2 installation
+
+Sometimes it is useful to add compiler flags after-the-fact to the set
+that were chosen by "configure". An important example is that gcc's
+"-Werror" option cannot be included in the CFLAGS passed to "configure",
+because it will break many of "configure"'s built-in tests. To add such
+flags, include them in the COPT environment variable while running
+"make". The contents of COPT are added to both the CFLAGS and LDFLAGS
+options set up by "configure". For example, you could do
+
+    make COPT='-Werror'
+
+or
+
+    export COPT='-Werror'
+    make
+
+Note:
+
+If using GCC, it is best to build with an optimization level of at least
+"-O1", because using no optimization ("-O0") disables some important
+compiler warnings (such as the use of uninitialized variables). However,
+non-zero optimization levels can complicate debugging because stepping
+through compiled code will usually not match up one-to-one with source
+code lines. If you get confused while trying to debug optimized code,
+recompile the specific files of interest with "-O0". An easy way to do
+this is by passing an option to make: "make PROFILE=-O0 file.o".
+
+The COPT and PROFILE environment variables are actually handled
+identically by the PostgreSQL makefiles. Which to use is a matter of
+preference, but a common habit among developers is to use PROFILE for
+one-time flag adjustments, while COPT might be kept set all the time.
+
+------------------------------------------------------------------------
+
+Post-Installation Setup
+
+------------------------------------------------------------------------
+
+Shared Libraries
+
+On some systems with shared libraries you need to tell the system how to
+find the newly installed shared libraries. The systems on which this is
+*not* necessary include FreeBSD, HP-UX, Linux, NetBSD, OpenBSD, and
+Solaris.
+
+The method to set the shared library search path varies between
+platforms, but the most widely-used method is to set the environment
+variable LD_LIBRARY_PATH like so: In Bourne shells ("sh", "ksh", "bash",
+"zsh"):
+
+    LD_LIBRARY_PATH=/usr/local/pgsql/lib
+    export LD_LIBRARY_PATH
+
+or in "csh" or "tcsh":
+
+    setenv LD_LIBRARY_PATH /usr/local/pgsql/lib
+
+Replace /usr/local/pgsql/lib with whatever you set "--libdir" to in Step
+1. You should put these commands into a shell start-up file such as
+"/etc/profile" or "~/.bash_profile". Some good information about the
+caveats associated with this method can be found at
+http://xahlee.info/UnixResource_dir/_/ldpath.html.
+
+On some systems it might be preferable to set the environment variable
+LD_RUN_PATH *before* building.
+
+On Cygwin, put the library directory in the PATH or move the ".dll"
+files into the "bin" directory.
+
+If in doubt, refer to the manual pages of your system (perhaps "ld.so"
+or "rld"). If you later get a message like:
+
+    psql: error in loading shared libraries
+    libpq.so.2.1: cannot open shared object file: No such file or directory
+
+then this step was necessary. Simply take care of it then.
+
+If you are on Linux and you have root access, you can run:
+
+    /sbin/ldconfig /usr/local/pgsql/lib
+
+(or equivalent directory) after installation to enable the run-time
+linker to find the shared libraries faster. Refer to the manual page of
+"ldconfig" for more information. On FreeBSD, NetBSD, and OpenBSD the
+command is:
+
+    /sbin/ldconfig -m /usr/local/pgsql/lib
+
+instead. Other systems are not known to have an equivalent command.
+
+------------------------------------------------------------------------
+
+Environment Variables
+
+If you installed into "/usr/local/pgsql" or some other location that is
+not searched for programs by default, you should add
+"/usr/local/pgsql/bin" (or whatever you set "--bindir" to in Step 1)
+into your PATH. Strictly speaking, this is not necessary, but it will
+make the use of PostgreSQL much more convenient.
+
+To do this, add the following to your shell start-up file, such as
+"~/.bash_profile" (or "/etc/profile", if you want it to affect all
+users):
+
+    PATH=/usr/local/pgsql/bin:$PATH
+    export PATH
+
+If you are using "csh" or "tcsh", then use this command:
+
+    set path = ( /usr/local/pgsql/bin $path )
+
+To enable your system to find the man documentation, you need to add
+lines like the following to a shell start-up file unless you installed
+into a location that is searched by default:
+
+    MANPATH=/usr/local/pgsql/share/man:$MANPATH
+    export MANPATH
+
+The environment variables PGHOST and PGPORT specify to client
+applications the host and port of the database server, overriding the
+compiled-in defaults. If you are going to run client applications
+remotely then it is convenient if every user that plans to use the
+database sets PGHOST. This is not required, however; the settings can be
+communicated via command line options to most client programs.
+
+------------------------------------------------------------------------
+
+Getting Started
+
+The following is a quick summary of how to get PostgreSQL up and running
+once installed. The main documentation contains more information.
+
+1.  Create a user account for the PostgreSQL server. This is the user
+    the server will run as. For production use you should create a
+    separate, unprivileged account ("postgres" is commonly used). If you
+    do not have root access or just want to play around, your own user
+    account is enough, but running the server as root is a security risk
+    and will not work.
+
+        adduser postgres
+
+2.  Create a database installation with the "initdb" command. To run
+    "initdb" you must be logged in to your PostgreSQL server account. It
+    will not work as root.
+
+        root# mkdir /usr/local/pgsql/data
+        root# chown postgres /usr/local/pgsql/data
+        root# su - postgres
+        postgres$ /usr/local/pgsql/bin/initdb -D /usr/local/pgsql/data
+
+    The "-D" option specifies the location where the data will be
+    stored. You can use any path you want, it does not have to be under
+    the installation directory. Just make sure that the server account
+    can write to the directory (or create it, if it doesn't already
+    exist) before starting "initdb", as illustrated here.
+
+3.  At this point, if you did not use the "initdb" -A option, you might
+    want to modify "pg_hba.conf" to control local access to the server
+    before you start it. The default is to trust all local users.
+
+4.  The previous "initdb" step should have told you how to start up the
+    database server. Do so now. The command should look something like:
+
+        /usr/local/pgsql/bin/pg_ctl -D /usr/local/pgsql/data start
+
+    To stop a server running in the background you can type:
+
+        /usr/local/pgsql/bin/pg_ctl -D /usr/local/pgsql/data stop
+
+5.  Create a database:
+
+        /usr/local/pgsql/bin/createdb testdb
+
+    Then enter:
+
+        /usr/local/pgsql/bin/psql testdb
+
+    to connect to that database. At the prompt you can enter SQL
+    commands and start experimenting.
+
+------------------------------------------------------------------------
+
+What Now?
+
+-   The PostgreSQL distribution contains a comprehensive documentation
+    set, which you should read sometime. After installation, the
+    documentation can be accessed by pointing your browser to
+    "/usr/local/pgsql/doc/html/index.html", unless you changed the
+    installation directories.
+
+    The first few chapters of the main documentation are the Tutorial,
+    which should be your first reading if you are completely new to SQL
+    databases. If you are familiar with database concepts then you want
+    to proceed with part on server administration, which contains
+    information about how to set up the database server, database users,
+    and authentication.
+
+-   Usually, you will want to modify your computer so that it will
+    automatically start the database server whenever it boots. Some
+    suggestions for this are in the documentation.
+
+-   Run the regression tests against the installed server (using "make
+    installcheck"). If you didn't run the tests before installation, you
+    should definitely do it now. This is also explained in the
+    documentation.
+
+-   By default, PostgreSQL is configured to run on minimal hardware.
+    This allows it to start up with almost any hardware configuration.
+    The default configuration is, however, not designed for optimum
+    performance. To achieve optimum performance, several server
+    parameters must be adjusted, the two most common being
+    shared_buffers and work_mem. Other parameters mentioned in the
+    documentation also affect performance.
+
+------------------------------------------------------------------------
+
+Supported Platforms
+
+A platform (that is, a CPU architecture and operating system
+combination) is considered supported by the PostgreSQL development
+community if the code contains provisions to work on that platform and
+it has recently been verified to build and pass its regression tests on
+that platform. Currently, most testing of platform compatibility is done
+automatically by test machines in the PostgreSQL Build Farm. If you are
+interested in using PostgreSQL on a platform that is not represented in
+the build farm, but on which the code works or can be made to work, you
+are strongly encouraged to set up a build farm member machine so that
+continued compatibility can be assured.
+
+In general, PostgreSQL can be expected to work on these CPU
+architectures: x86, x86_64, IA64, PowerPC, PowerPC 64, S/390, S/390x,
+Sparc, Sparc 64, ARM, MIPS, MIPSEL, and PA-RISC. Code support exists for
+M68K, M32R, and VAX, but these architectures are not known to have been
+tested recently. It is often possible to build on an unsupported CPU
+type by configuring with "--disable-spinlocks", but performance will be
+poor.
+
+PostgreSQL can be expected to work on these operating systems: Linux
+(all recent distributions), Windows (XP and later), FreeBSD, OpenBSD,
+NetBSD, macOS, AIX, HP/UX, and Solaris. Other Unix-like systems may also
+work but are not currently being tested. In most cases, all CPU
+architectures supported by a given operating system will work. Look in
+the section called "Platform-Specific Notes" below to see if there is
+information specific to your operating system, particularly if using an
+older system.
+
+If you have installation problems on a platform that is known to be
+supported according to recent build farm results, please report it to
+<pgsql-bugs@lists.postgresql.org>. If you are interested in porting
+PostgreSQL to a new platform, <pgsql-hackers@lists.postgresql.org> is
+the appropriate place to discuss that.
+
+------------------------------------------------------------------------
+
+Platform-Specific Notes
+
+This section documents additional platform-specific issues regarding the
+installation and setup of PostgreSQL. Be sure to read the installation
+instructions, and in particular the section called "Requirements" as
+well. Also, check the file "src/test/regress/README" and the
+documentation regarding the interpretation of regression test results.
+
+Platforms that are not covered here have no known platform-specific
+installation issues.
+
+------------------------------------------------------------------------
+
+AIX
+
+You can use GCC or the native IBM compiler "xlc" to build PostgreSQL on
+AIX.
+
+AIX versions before 7.1 are no longer tested nor supported by the
+PostgreSQL community.
+
+------------------------------------------------------------------------
+
+Memory Management
+
+AIX can be somewhat peculiar with regards to the way it does memory
+management. You can have a server with many multiples of gigabytes of
+RAM free, but still get out of memory or address space errors when
+running applications. One example is loading of extensions failing with
+unusual errors. For example, running as the owner of the PostgreSQL
+installation:
+
+    =# CREATE EXTENSION plperl;
+    ERROR:  could not load library "/opt/dbs/pgsql/lib/plperl.so": A memory address is not in the address space for the process.
+
+Running as a non-owner in the group possessing the PostgreSQL
+installation:
+
+    =# CREATE EXTENSION plperl;
+    ERROR:  could not load library "/opt/dbs/pgsql/lib/plperl.so": Bad address
+
+Another example is out of memory errors in the PostgreSQL server logs,
+with every memory allocation near or greater than 256 MB failing.
+
+The overall cause of all these problems is the default bittedness and
+memory model used by the server process. By default, all binaries built
+on AIX are 32-bit. This does not depend upon hardware type or kernel in
+use. These 32-bit processes are limited to 4 GB of memory laid out in
+256 MB segments using one of a few models. The default allows for less
+than 256 MB in the heap as it shares a single segment with the stack.
+
+In the case of the plperl example, above, check your umask and the
+permissions of the binaries in your PostgreSQL installation. The
+binaries involved in that example were 32-bit and installed as mode 750
+instead of 755. Due to the permissions being set in this fashion, only
+the owner or a member of the possessing group can load the library.
+Since it isn't world-readable, the loader places the object into the
+process' heap instead of the shared library segments where it would
+otherwise be placed.
+
+The "ideal" solution for this is to use a 64-bit build of PostgreSQL,
+but that is not always practical, because systems with 32-bit processors
+can build, but not run, 64-bit binaries.
+
+If a 32-bit binary is desired, set LDR_CNTRL to MAXDATA=0xn0000000,
+where 1 <= n <= 8, before starting the PostgreSQL server, and try
+different values and "postgresql.conf" settings to find a configuration
+that works satisfactorily. This use of LDR_CNTRL tells AIX that you want
+the server to have MAXDATA bytes set aside for the heap, allocated in
+256 MB segments. When you find a workable configuration, "ldedit" can be
+used to modify the binaries so that they default to using the desired
+heap size. PostgreSQL can also be rebuilt, passing
+configure      LDFLAGS="-Wl,-bmaxdata:0xn0000000" to achieve the same
+effect.
+
+For a 64-bit build, set OBJECT_MODE to 64 and pass CC="gcc -maix64" and
+LDFLAGS="-Wl,-bbigtoc" to "configure". (Options for "xlc" might differ.)
+If you omit the export of OBJECT_MODE, your build may fail with linker
+errors. When OBJECT_MODE is set, it tells AIX's build utilities such as
+"ar", "as", and "ld" what type of objects to default to handling.
+
+By default, overcommit of paging space can happen. While we have not
+seen this occur, AIX will kill processes when it runs out of memory and
+the overcommit is accessed. The closest to this that we have seen is
+fork failing because the system decided that there was not enough memory
+for another process. Like many other parts of AIX, the paging space
+allocation method and out-of-memory kill is configurable on a system- or
+process-wide basis if this becomes a problem.
+
+------------------------------------------------------------------------
+
+Cygwin
+
+PostgreSQL can be built using Cygwin, a Linux-like environment for
+Windows, but that method is inferior to the native Windows build and
+running a server under Cygwin is no longer recommended.
+
+When building from source, proceed according to the Unix-style
+installation procedure (i.e., ./configure;     make; etc.), noting the
+following Cygwin-specific differences:
+
+-   Set your path to use the Cygwin bin directory before the Windows
+    utilities. This will help prevent problems with compilation.
+
+-   The "adduser" command is not supported; use the appropriate user
+    management application on Windows NT, 2000, or XP. Otherwise, skip
+    this step.
+
+-   The "su" command is not supported; use ssh to simulate su on Windows
+    NT, 2000, or XP. Otherwise, skip this step.
+
+-   OpenSSL is not supported.
+
+-   Start "cygserver" for shared memory support. To do this, enter the
+    command /usr/sbin/cygserver        &. This program needs to be
+    running anytime you start the PostgreSQL server or initialize a
+    database cluster ("initdb"). The default "cygserver" configuration
+    may need to be changed (e.g., increase SEMMNS) to prevent PostgreSQL
+    from failing due to a lack of system resources.
+
+-   Building might fail on some systems where a locale other than C is
+    in use. To fix this, set the locale to C by doing "export
+    LANG=C.utf8" before building, and then setting it back to the
+    previous setting after you have installed PostgreSQL.
+
+-   The parallel regression tests (make check) can generate spurious
+    regression test failures due to overflowing the listen() backlog
+    queue which causes connection refused errors or hangs. You can limit
+    the number of connections using the make variable MAX_CONNECTIONS
+    thus:
+
+        make MAX_CONNECTIONS=5 check
+
+    (On some systems you can have up to about 10 simultaneous
+    connections.)
+
+It is possible to install "cygserver" and the PostgreSQL server as
+Windows NT services. For information on how to do this, please refer to
+the "README" document included with the PostgreSQL binary package on
+Cygwin. It is installed in the directory "/usr/share/doc/Cygwin".
+
+------------------------------------------------------------------------
+
+macOS
+
+To build PostgreSQL from source on macOS, you will need to install
+Apple's command line developer tools, which can be done by issuing
+
+    xcode-select --install
+
+(note that this will pop up a GUI dialog window for confirmation). You
+may or may not wish to also install Xcode.
+
+On recent macOS releases, it's necessary to embed the "sysroot" path in
+the include switches used to find some system header files. This results
+in the outputs of the configure script varying depending on which SDK
+version was used during configure. 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
+PG_SYSROOT, for example
+
+    make PG_SYSROOT=/desired/path all
+
+To find out the appropriate path on your machine, run
+
+    xcrun --show-sdk-path
+
+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.
+
+You can also select a non-default sysroot path when configuring, by
+specifying PG_SYSROOT to configure:
+
+    ./configure ... PG_SYSROOT=/desired/path
+
+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.
+
+To suppress the "-isysroot" options altogether, use
+
+    ./configure ... PG_SYSROOT=none
+
+(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.
+
+macOS's "System Integrity Protection" (SIP) feature breaks make check,
+because it prevents passing the needed setting of DYLD_LIBRARY_PATH down
+to the executables being tested. You can work around that by doing
+make     install before make check. Most PostgreSQL developers just turn
+off SIP, though.
+
+------------------------------------------------------------------------
+
+MinGW/Native Windows
+
+PostgreSQL for Windows can be built using MinGW, a Unix-like build
+environment for Microsoft operating systems, or using Microsoft's Visual
+C++ compiler suite. The MinGW build procedure uses the normal build
+system described in this chapter; the Visual C++ build works completely
+differently and is described in the documentation.
+
+The native Windows port requires a 32 or 64-bit version of Windows 2000
+or later. Earlier operating systems do not have sufficient
+infrastructure (but Cygwin may be used on those). MinGW, the Unix-like
+build tools, and MSYS, a collection of Unix tools required to run shell
+scripts like "configure", can be downloaded from http://www.mingw.org/.
+Neither is required to run the resulting binaries; they are needed only
+for creating the binaries.
+
+To build 64 bit binaries using MinGW, install the 64 bit tool set from
+https://mingw-w64.org/, put its bin directory in the PATH, and run
+"configure" with the "--host=x86_64-w64-mingw32" option.
+
+After you have everything installed, it is suggested that you run psql
+under "CMD.EXE", as the MSYS console has buffering issues.
+
+------------------------------------------------------------------------
+
+Collecting Crash Dumps on Windows
+
+If PostgreSQL on Windows crashes, it has the ability to generate
+minidumps that can be used to track down the cause for the crash,
+similar to core dumps on Unix. These dumps can be read using the Windows
+Debugger Tools or using Visual Studio. To enable the generation of dumps
+on Windows, create a subdirectory named "crashdumps" inside the cluster
+data directory. The dumps will then be written into this directory with
+a unique name based on the identifier of the crashing process and the
+current time of the crash.
+
+------------------------------------------------------------------------
+
+Solaris
+
+PostgreSQL is well-supported on Solaris. The more up to date your
+operating system, the fewer issues you will experience.
+
+------------------------------------------------------------------------
+
+Required Tools
+
+You can build with either GCC or Sun's compiler suite. For better code
+optimization, Sun's compiler is strongly recommended on the SPARC
+architecture. If you are using Sun's compiler, be careful not to select
+"/usr/ucb/cc"; use "/opt/SUNWspro/bin/cc".
+
+You can download Sun Studio from
+https://www.oracle.com/technetwork/server-storage/solarisstudio/downloads/.
+Many GNU tools are integrated into Solaris 10, or they are present on
+the Solaris companion CD. If you need packages for older versions of
+Solaris, you can find these tools at http://www.sunfreeware.com. If you
+prefer sources, look at https://www.gnu.org/prep/ftp.
+
+------------------------------------------------------------------------
+
+configure Complains About a Failed Test Program
+
+If "configure" complains about a failed test program, this is probably a
+case of the run-time linker being unable to find some library, probably
+libz, libreadline or some other non-standard library such as libssl. To
+point it to the right location, set the LDFLAGS environment variable on
+the "configure" command line, e.g.,
+
+    configure ... LDFLAGS="-R /usr/sfw/lib:/opt/sfw/lib:/usr/local/lib"
+
+See the ld man page for more information.
+
+------------------------------------------------------------------------
+
+Compiling for Optimal Performance
+
+On the SPARC architecture, Sun Studio is strongly recommended for
+compilation. Try using the "-xO5" optimization flag to generate
+significantly faster binaries. Do not use any flags that modify behavior
+of floating-point operations and errno processing (e.g., "-fast").
+
+If you do not have a reason to use 64-bit binaries on SPARC, prefer the
+32-bit version. The 64-bit operations are slower and 64-bit binaries are
+slower than the 32-bit variants. On the other hand, 32-bit code on the
+AMD64 CPU family is not native, so 32-bit code is significantly slower
+on that CPU family.
+
+------------------------------------------------------------------------
+
+Using DTrace for Tracing PostgreSQL
+
+Yes, using DTrace is possible. See the documentation for further
+information.
+
+If you see the linking of the "postgres" executable abort with an error
+message like:
+
+    Undefined                       first referenced
+     symbol                             in file
+    AbortTransaction                    utils/probes.o
+    CommitTransaction                   utils/probes.o
+    ld: fatal: Symbol referencing errors. No output written to postgres
+    collect2: ld returned 1 exit status
+    make: *** [postgres] Error 1
+
+your DTrace installation is too old to handle probes in static
+functions. You need Solaris 10u4 or newer to use DTrace.