diff options
Diffstat (limited to 'INSTALL')
| -rw-r--r-- | INSTALL | 1572 |
1 files changed, 1572 insertions, 0 deletions
@@ -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. |