From 5ba1fab5fa2860da278f8945a2ef77b2e42bf015 Mon Sep 17 00:00:00 2001 From: Bruce Momjian Date: Sat, 4 Oct 2003 03:14:13 +0000 Subject: [PATCH] Update INSTALL file for 7.4. --- INSTALL | 1634 +++++++++++++++----------------- doc/src/sgml/installation.sgml | 10 +- 2 files changed, 790 insertions(+), 854 deletions(-) diff --git a/INSTALL b/INSTALL index 9d5dd94008..1a62ee7bf9 100644 --- a/INSTALL +++ b/INSTALL @@ -1,879 +1,813 @@ - PostgreSQL Installation Instructions - -This document describes the installation of PostgreSQL from the source code -distribution. - -------------------------------------------------------------------------------- - - Short Version - - ./configure - gmake - su - gmake install - adduser postgres - mkdir /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/postmaster -D /usr/local/pgsql/data >logfile 2>&1 & - /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 -listed in the Section called Supported Platforms below. In the "doc" -subdirectory of the distribution there are several platform-specific FAQ -documents you might wish to consult if you are having trouble. -The following software packages are required for building PostgreSQL: - - * GNU make is required; other make programs will *not* work. GNU make is - often installed under the name "gmake"; this document will always refer - to it by that name. (On some systems GNU make is the default tool with - the name "make".) To test for GNU make enter - - gmake --version - - It is recommended to use version 3.76.1 or later. - - * You need an ISO/ANSI C compiler. Recent versions of GCC are - recommendable, but PostgreSQL is known to build with a wide variety of - compilers from different vendors. - - * gzip is needed to unpack the distribution in the first place. If you are - reading this, you probably already got past that hurdle. - - * The GNU Readline library (for comfortable line editing and command - history retrieval) will be used by default. If you don't want to use it - then you must specify the "--without-readline" option for "configure". - (On NetBSD, the "libedit" library is readline-compatible and is used if - "libreadline" is not found.) - - * To build on Windows NT or Windows 2000 you need the Cygwin and cygipc - packages. See the file "doc/FAQ_MSWIN" for details. - -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. 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 general it is - the choice of whomever installed Perl at your site. - If you don't have the shared library but you need one, a message like - this will appear during the build to point out this fact: - - *** Cannot build PL/Perl because libperl is not a shared library. - *** You might have to rebuild your Perl installation. Refer to - *** the documentation for details. - - (If you don't follow the on-screen output you will merely notice that the - PL/Perl library object, "plperl.so" or similar, will not be installed.) - If you see this, 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. - - * To build the Python interface module or the PL/Python server programming - language, you need a Python installation, including the header files. - 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. - If after building and installing you have a file called "plpython.so" - (possibly a different extension), then everything went well. Otherwise - you should have seen a notice like this flying by: - - *** Cannot build PL/Python because libpython is not a shared library. - *** You might have to rebuild your Python installation. Refer to - *** the documentation for details. - - That means you have to rebuild (part of) your Python installation to - supply this shared library. - The catch is that the Python distribution or the Python maintainers do - not provide any direct way to do this. The closest thing we can offer you - is the information in Python FAQ 3.30. On some operating systems you - don't really have to build a shared library, but then you will have to - convince the PostgreSQL build system of this. Consult the "Makefile" in - the "src/pl/plpython" directory for details. - - * If you want to build Tcl or Tk components (clients and the PL/Tcl - language) you of course need a Tcl installation. - - * To build the JDBC driver, you need Ant 1.5 or higher and a JDK. Ant is a - special tool for building Java-based packages. It can be downloaded from - the Ant web site. - If you have several Java compilers installed, it depends on the Ant - configuration which one gets used. Precompiled Ant distributions are - typically set up to read a file ".antrc" in the current user's home - directory for configuration. For example, to use a different JDK than the - default, this may work: - - JAVA_HOME=/usr/local/sun-jdk1.3 - JAVACMD=$JAVA_HOME/bin/java - - Note: Do not try to build the driver by calling "ant" or even - "javac" directly. This will not work. Run "gmake" normally as - described below. - - * 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 here: http://www.postgresql.org/~petere/ - gettext.html. 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. - - * Kerberos, OpenSSL, or PAM, if you want to support authentication using - these services. - -If you are build from a CVS tree instead of using a released source package, or -if you want to do development, you also need the following packages: - - * Flex and Bison are needed to build a CVS checkout or if you changed the - actual scanner and parser definition files. If you need them, be sure to - get Flex 2.5.4 or later and Bison 1.50 or later. Other yacc programs can - sometimes be used, but doing so requires extra effort and is not - recommended. Other lex programs will definitely not work. - -If you need to get a GNU package, you can find it at your local GNU mirror site -(see http://www.gnu.org/order/ftp.html for a list) or at ftp://ftp.gnu.org/ -gnu/. -Also check that you have sufficient disk space. You will need about 65 MB for -the source tree during compilation and about 15 MB for the installation -directory. An empty database cluster takes about 25 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 90 MB. Use the "df" command to check for disk space. - -------------------------------------------------------------------------------- - - If You Are Upgrading - -The internal data storage format changes with new releases of PostgreSQL. -Therefore, if you are upgrading an existing installation that does not have a -version number "7.3.x", you must back up and restore your data as shown here. -These instructions assume that your existing installation is under the "/usr/ -local/pgsql" directory, and that the data area is in "/usr/local/pgsql/data". -Substitute your paths appropriately. - - 1. Make sure that your database is not updated during or after the backup. - This does not affect the integrity of the backup, but the changed data - would of course not be included. If necessary, edit the permissions in - the file "/usr/local/pgsql/data/pg_hba.conf" (or equivalent) to disallow - access from everyone except you. - - 2. To back up your database installation, type: - - pg_dumpall > outputfile - - If you need to preserve OIDs (such as when using them as foreign keys), - then use the "-o" option when running "pg_dumpall". - "pg_dumpall" does not save large objects. Check the Administrator's Guide - if you need to do this. - To make the backup, you can use the "pg_dumpall" command from the version - you are currently running. For best results, however, try to use the - "pg_dumpall" command from PostgreSQL 7.3, since this version contains - bug fixes and improvements over older versions. While this advice might - seem idiosyncratic since you haven't installed the new version yet, it is - advisable to follow it if you plan to install the new version in parallel - with the old version. In that case you can complete the installation - normally and transfer the data later. This will also decrease the - downtime. - - 3. If you are installing the new version at the same location as the old one - then shut down the old server, at the latest before you install the new - files: - - kill -INT `cat /usr/local/pgsql/data/postmaster.pid` - - Versions prior to 7.0 do not have this "postmaster.pid" file. If you are - using such a version you must find out the process id of the server - yourself, for example by typing "ps ax | grep postmaster", and supply it - to the "kill" command. - On systems that have PostgreSQL started at boot time, there is probably a - start-up file that will accomplish the same thing. For example, on a Red - Hat Linux system one might find that - - /etc/rc.d/init.d/postgresql stop - - works. Another possibility is "pg_ctl stop". - - 4. If you are installing in the same place as the old version then it is - also a good idea to move the old installation out of the way, in case you - have trouble and need to revert to it. Use a command like this: - - mv /usr/local/pgsql /usr/local/pgsql.old - -After you have installed PostgreSQL 7.3, create a new database directory and -start the new server. Remember that you must execute these commands while -logged in to the special database user account (which you already have if you -are upgrading). - - /usr/local/pgsql/bin/initdb -D /usr/local/pgsql/data - /usr/local/pgsql/bin/postmaster -D /usr/local/pgsql/data - -Finally, restore your data with - - /usr/local/pgsql/bin/psql -d template1 -f outputfile - -using the *new* psql. -These topics are discussed at length in the Administrator's Guide, which you -are encouraged to read in any case. - -------------------------------------------------------------------------------- - - 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 guess values for various system - dependent variables and detect some 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 if you want to keep the build directory separate.) - 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 of the following command line options to "configure": - + PostgreSQL Installation Instructions + + This document describes the installation of PostgreSQL from the source + code distribution. + _________________________________________________________________ + + Short Version + +./configure +gmake +su +gmake install +adduser postgres +mkdir /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/postmaster -D /usr/local/pgsql/data >logfile 2>&1 & +/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 listed in the section called Supported Platforms + below. In the "doc" subdirectory of the distribution there are several + platform-specific FAQ documents you might wish to consult if you are + having trouble. + + The following software packages are required for building PostgreSQL: + + * GNU make is required; other make programs will *not* work. GNU + make is often installed under the name "gmake"; this document will + always refer to it by that name. (On some systems GNU make is the + default tool with the name "make".) To test for GNU make enter +gmake --version + It is recommended to use version 3.76.1 or later. + * You need an ISO/ANSI C compiler. Recent versions of GCC are + recommendable, but PostgreSQL is known to build with a wide + variety of compilers from different vendors. + * gzip is needed to unpack the distribution in the first place. If + you are reading this, you probably already got past that hurdle. + * The GNU Readline library (for comfortable line editing and command + history retrieval) will be used by default. If you don't want to + use it then you must specify the "--without-readline" option for + "configure". (On NetBSD, the "libedit" library is + Readline-compatible and is used if "libreadline" is not found.) + * To build on Windows NT or Windows 2000 you need the Cygwin and + cygipc packages. See the file "doc/FAQ_MSWIN" for details. + + 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. 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 general it is the choice of whomever + installed Perl at your site. + If you don't have the shared library but you need one, a message + like this will appear during the build to point out this fact: +*** Cannot build PL/Perl because libperl is not a shared library. +*** You might have to rebuild your Perl installation. Refer to +*** the documentation for details. + (If you don't follow the on-screen output you will merely notice + that the PL/Perl library object, "plperl.so" or similar, will not + be installed.) If you see this, 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. + * To build the PL/Python server programming language, you need a + Python installation, including the header files. 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. + If after building and installing you have a file called + "plpython.so" (possibly a different extension), then everything + went well. Otherwise you should have seen a notice like this + flying by: +*** Cannot build PL/Python because libpython is not a shared library. +*** You might have to rebuild your Python installation. Refer to +*** the documentation for details. + That means you have to rebuild (part of) your Python installation + to supply this shared library. + The catch is that the Python distribution or the Python + maintainers do not provide any direct way to do this. The closest + thing we can offer you is the information in Python FAQ 3.30. On + some operating systems you don't really have to build a shared + library, but then you will have to convince the PostgreSQL build + system of this. Consult the "Makefile" in the "src/pl/plpython" + directory for details. + * If you want to build Tcl or Tk components (clients and the PL/Tcl + language) you of course need a Tcl installation. + * To build the JDBC driver, you need Ant 1.5 or higher and a JDK. + Ant is a special tool for building Java-based packages. It can be + downloaded from the Ant web site. + If you have several Java compilers installed, it depends on the + Ant configuration which one gets used. Precompiled Ant + distributions are typically set up to read a file ".antrc" in the + current user's home directory for configuration. For example, to + use a different JDK than the default, this may work: +JAVA_HOME=/usr/local/sun-jdk1.3 +JAVACMD=$JAVA_HOME/bin/java + + Note: Do not try to build the driver by calling "ant" or even + "javac" directly. This will not work. Run "gmake" normally as + described below. + * 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 here: + http://www.postgresql.org/~petere/gettext.html. 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. + * Kerberos, OpenSSL, or PAM, if you want to support authentication + using these services. + + If you are building from a CVS tree instead of using a released source + package, or if you want to do development, you also need the following + packages: + + * Flex and Bison are needed to build a CVS checkout or if you + changed the actual scanner and parser definition files. If you + need them, be sure to get Flex 2.5.4 or later and Bison 1.875 or + later. Other yacc programs can sometimes be used, but doing so + requires extra effort and is not recommended. Other lex programs + will definitely not work. + + If you need to get a GNU package, you can find it at your local GNU + mirror site (see http://www.gnu.org/order/ftp.html for a list) or at + ftp://ftp.gnu.org/gnu/. + + Also check that you have sufficient disk space. You will need about 65 + MB for the source tree during compilation and about 15 MB for the + installation directory. An empty database cluster takes about 25 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 90 MB. Use + the "df" command to check for disk space. + _________________________________________________________________ + + If You Are Upgrading + + The internal data storage format changes with new releases of + PostgreSQL. Therefore, if you are upgrading an existing installation + that does not have a version number "7.4.x", you must back up and + restore your data as shown here. These instructions assume that your + existing installation is under the "/usr/local/pgsql" directory, and + that the data area is in "/usr/local/pgsql/data". Substitute your + paths appropriately. + 1. Make sure that your database is not updated during or after the + backup. This does not affect the integrity of the backup, but the + changed data would of course not be included. If necessary, edit + the permissions in the file "/usr/local/pgsql/data/pg_hba.conf" + (or equivalent) to disallow access from everyone except you. + 2. To back up your database installation, type: +pg_dumpall > outputfile + If you need to preserve OIDs (such as when using them as foreign + keys), then use the "-o" option when running "pg_dumpall". + "pg_dumpall" does not save large objects. Check the documentation + if you need to do this. + To make the backup, you can use the "pg_dumpall" command from the + version you are currently running. For best results, however, try + to use the "pg_dumpall" command from PostgreSQL 7.4beta4, since + this version contains bug fixes and improvements over older + versions. While this advice might seem idiosyncratic since you + haven't installed the new version yet, it is advisable to follow + it if you plan to install the new version in parallel with the old + version. In that case you can complete the installation normally + and transfer the data later. This will also decrease the downtime. + 3. If you are installing the new version at the same location as the + old one then shut down the old server, at the latest before you + install the new files: +kill -INT `cat /usr/local/pgsql/data/postmaster.pid` + Versions prior to 7.0 do not have this "postmaster.pid" file. If + you are using such a version you must find out the process ID of + the server yourself, for example by typing "ps ax | grep + postmaster", and supply it to the "kill" command. + On systems that have PostgreSQL started at boot time, there is + probably a start-up file that will accomplish the same thing. For + example, on a Red Hat Linux system one might find that +/etc/rc.d/init.d/postgresql stop + works. Another possibility is "pg_ctl stop". + 4. If you are installing in the same place as the old version then it + is also a good idea to move the old installation out of the way, + in case you have trouble and need to revert to it. Use a command + like this: +mv /usr/local/pgsql /usr/local/pgsql.old + + After you have installed PostgreSQL 7.4beta4, create a new database + directory and start the new server. Remember that you must execute + these commands while logged in to the special database user account + (which you already have if you are upgrading). +/usr/local/pgsql/bin/initdb -D /usr/local/pgsql/data +/usr/local/pgsql/bin/postmaster -D /usr/local/pgsql/data + + Finally, restore your data with +/usr/local/pgsql/bin/psql -d template1 -f outputfile + + using the *new* psql. + + These topics are discussed at length in the documentation, which you + are encouraged to read in any case. + _________________________________________________________________ + + 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 guess values for various + system dependent variables and detect some 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 if you want to keep the + build directory separate.) + 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 of the following command line options to "configure": + --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. - If you have special needs, you can also customize the individual - subdirectories with the following options. - + 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. + + If you have special needs, you can also customize the + individual subdirectories with the following options. + --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. - + 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". - + Specifies the directory for executable programs. The + default is "EXEC-PREFIX/bin", which normally means + "/usr/local/pgsql/bin". + --datadir=DIRECTORY - - Sets the directory for read-only data files used by the installed - programs. The default is "PREFIX/share". Note that this has nothing - to do with where your database files will be placed. - + Sets the directory for read-only data files used by the + installed programs. The default is "PREFIX/share". Note + that this has nothing to do with where your database + files will be placed. + --sysconfdir=DIRECTORY - - The directory for various configuration files, "PREFIX/etc" by - default. - + The directory for various configuration files, + "PREFIX/etc" by default. + --libdir=DIRECTORY - - The location to install libraries and dynamically loadable modules. - The default is "EXEC-PREFIX/lib". - + The location to install libraries and dynamically + loadable modules. The default is "EXEC-PREFIX/lib". + --includedir=DIRECTORY - - The directory for installing C and C++ header files. The default is - "PREFIX/include". - + The directory for installing C and C++ header files. The + default is "PREFIX/include". + --docdir=DIRECTORY - - Documentation files, except "man" pages, will be installed into - this directory. The default is "PREFIX/doc". - + Documentation files, except "man" pages, will be + installed into this directory. The default is + "PREFIX/doc". + --mandir=DIRECTORY - - The man pages that come with PostgreSQL will be installed under - this directory, in their respective "manx" subdirectories. The - default is "PREFIX/man". - 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 Programmer's Guide for information - about how to get at the header files for each interface. - Finally, a private subdirectory will also be created, if - appropriate, under libdir for dynamically loadable modules. - + The man pages that come with PostgreSQL will be installed + under this directory, in their respective "manx" + subdirectories. The default is "PREFIX/man". + + 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 get at the its header + files. Finally, a private subdirectory will also be created, if + appropriate, under libdir for dynamically loadable modules. + --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. - + "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. - + "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. + --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 a 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; see above. - + Enables Native Language Support (NLS), that is, the + ability to display a program's messages in a language + other than English. "LANGUAGES" is a 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; see above. + --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. - + 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-perl - - Build the PL/Perl server-side language. - + Build the PL/Perl server-side language. + --with-python - - Build the Python interface module and the PL/Python server-side - language. You need to have root access to be able to install the - Python module at its default place ("/usr/lib/pythonx.y"). - + Build the PL/Python server-side language. + --with-tcl - - Build components that require Tcl/Tk, which are libpgtcl, pgtclsh, - pgtksh, and PL/Tcl. But see below about "--without-tk". - + Build components that require Tcl/Tk, which are libpgtcl, + pgtclsh, pgtksh, and PL/Tcl. But see below about + "--without-tk". + --without-tk - - If you specify "--with-tcl" and this option, then the program that - requires Tk (pgtksh) will be excluded. - + If you specify "--with-tcl" and this option, then the + program that requires Tk (pgtksh) will be excluded. + --with-tclconfig=DIRECTORY, --with-tkconfig=DIRECTORY - - Tcl/Tk installs the files "tclConfig.sh" and "tkConfig.sh", which - contain configuration information needed to build modules - interfacing to Tcl or Tk. These files are normally found - automatically at their well-known locations, but if you want to use - a different version of Tcl or Tk you can specify the directory in - which to find them. - + Tcl/Tk installs the files "tclConfig.sh" and + "tkConfig.sh", which contain configuration information + needed to build modules interfacing to Tcl or Tk. These + files are normally found automatically at their + well-known locations, but if you want to use a different + version of Tcl or Tk you can specify the directory in + which to find them. + --with-java - - Build the JDBC driver and associated Java packages. - + Build the JDBC driver and associated Java packages. + --with-krb4[=DIRECTORY], --with-krb5[=DIRECTORY] - - Build with support for Kerberos authentication. You can use either - Kerberos version 4 or 5, but not both. The "DIRECTORY" argument - specifies the root directory of the Kerberos installation; "/usr/ - athena" is assumed as default. If the relevant header files and - libraries are not under a common parent directory, then you must - use the "--with-includes" and "--with-libraries" options in - addition to this option. If, on the other hand, the required files - are in a location that is searched by default (e.g., "/usr/lib"), - then you can leave off the argument. - "configure" will check for the required header files and libraries - to make sure that your Kerberos installation is sufficient before - proceeding. - + Build with support for Kerberos authentication. You can + use either Kerberos version 4 or 5, but not both. The + "DIRECTORY" argument specifies the root directory of the + Kerberos installation; "/usr/athena" is assumed as + default. If the relevant header files and libraries are + not under a common parent directory, then you must use + the "--with-includes" and "--with-libraries" options in + addition to this option. If, on the other hand, the + required files are in a location that is searched by + default (e.g., "/usr/lib"), then you can leave off the + argument. + + "configure" will check for the required header files and + libraries to make sure that your Kerberos installation is + sufficient before proceeding. + --with-krb-srvnam=NAME - - The name of the Kerberos service principal. postgres is the - default. There's probably no reason to change this. - + The name of the Kerberos service principal. postgres is + the default. There's probably no reason to change this. + --with-openssl[=DIRECTORY] - - Build with support for SSL (encrypted) connections. This requires - the OpenSSL package to be installed. The "DIRECTORY" argument - specifies the root directory of the OpenSSL installation; the - default is "/usr/local/ssl". - "configure" will check for the required header files and libraries - to make sure that your OpenSSL installation is sufficient before - proceeding. - + Build with support for SSL (encrypted) connections. This + requires the OpenSSL package to be installed. The + "DIRECTORY" argument specifies the root directory of the + OpenSSL installation; the default is "/usr/local/ssl". + + "configure" will check for the required header files and + libraries to make sure that your OpenSSL installation is + sufficient before proceeding. + --with-pam - - Build with PAM (Pluggable Authentication Modules) support. - + Build with PAM (Pluggable Authentication Modules) + support. + --without-readline - - Prevents the use of the Readline library. This disables command- - line editing and history in psql, so it is not recommended. - + Prevents the use of the Readline library. This disables + command-line editing and history in psql, so it is not + recommended. + + --with-rendezvous + Build with Rendezvous support. + + --disable-spinlocks + Allows source builds to succeed without CPU spinlock + support. Lack of spinlock support will produce poor + performance. This option is to be used only by platforms + lacking spinlock support. + + --enable-thread-safety + Allow separate libpq and ecpg threads to safely control + their private connection handles. + --without-zlib - - Prevents the use of the Zlib library. This disables compression - support in pg_dump. This option is only intended for those rare - systems where this library is not available. - + Prevents the use of the Zlib library. This disables + compression support in pg_dump. This option is only + intended for those rare systems where this library is not + available. + --enable-debug - - Compiles all programs and libraries with debugging symbols. This - means that you can run the programs through 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 may 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. - + Compiles all programs and libraries with debugging + symbols. This means that you can run the programs through + 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 + may 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 "can't - happen" conditions. This is invaluable for code development - purposes, but the tests slow things down a little. 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. Currently, - this option is not recommended for production use, but you should - have it on for development work or when running a beta version. - + Enables assertion checks in the server, which test for + many "can't happen" conditions. This is invaluable for + code development purposes, but the tests slow things down + a little. 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. + Currently, this option is not recommended for production + use, but you should have it on for development work or + when running a beta version. + --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 will work - only if you use GCC. - - If you prefer a C compiler different from the one "configure" picks then - you can set the environment variable CC to the program of your choice. By - default, "configure" will pick "gcc" unless this is inappropriate for the - platform. Similarly, you can override the default compiler flags with the - CFLAGS variable. - - You can specify environment variables on the "configure" command line, - for example: - - ./configure CC=/opt/bin/gcc CFLAGS='-O2 -pipe' - - 2. Build - To start the build, type - - gmake - - (Remember to use GNU make.) The build may take anywhere from 5 minutes to - half an hour depending on your hardware. The last line displayed should - be - - All of PostgreSQL is successfully made. Ready to install. - - 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 - - gmake check - - (This won't work as root; do it as an unprivileged user.) It is possible - that some tests fail, due to differences in error message wording or - floating point results. The file "src/test/regress/README" and the - Administrator's Guide contain 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 and are going to - install the new files over the old ones, then you should have - backed up your data and shut down the old server by now, as - explained in the Section called If You Are Upgrading above. - To install PostgreSQL enter - - gmake 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 could - create the target directories in advance and arrange for appropriate - permissions to be granted. - You can use gmake install-strip instead of gmake 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. - If you built the Python interfaces and you were not the root user when - you executed the above command then that part of the installation - probably failed. In that case you should become the root user and then do - - gmake -C src/interfaces/python install - - If you do not have superuser access you are on your own: you can still - take the required files and place them in other directories where Python - can find them, but how to do that is left as an exercise. - The standard installation provides only the header files needed for - client application development. If you plan to do any server-side program - development (such as custom functions or data types written in C), then - you may want to install the entire PostgreSQL include tree into your - target include directory. To do that, enter - - gmake install-all-headers - - This adds a megabyte or two to the installation footprint, and is only - useful if you don't plan to keep the whole source tree around for - reference. (If you do, you can just use the source's include directory - when building server-side software.) - Client-only installation: If you want to install only the client - applications and interface libraries, then you can use these commands: - - gmake -C src/bin install - gmake -C src/include install - gmake -C src/interfaces install - gmake -C doc install - -Uninstallation: To undo the installation use the command "gmake uninstall". -However, this will not remove any created directories. -Cleaning: After the installation you can make room by removing the built files -from the source tree with the command "gmake clean". This will preserve the -files made by the configure program, so that you can rebuild everything with -"gmake" later on. To reset the source tree to the state in which it was -distributed, use "gmake distclean". If you are going to build for several -platforms from the same source tree you must do this and re-configure for each -build. -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 "gmake distclean" before -reconfiguring and rebuilding. Without this, your changes in configuration -choices may not propagate everywhere they need to. - -------------------------------------------------------------------------------- - - Post-Installation Setup - -Shared Libraries - -On some systems that have shared libraries (which most systems do) you need to -tell your system how to find the newly installed shared libraries. The systems -on which this is *not* necessary include BSD/OS, FreeBSD, HP-UX, IRIX, Linux, -NetBSD, OpenBSD, Tru64 UNIX (formerly Digital UNIX), and Solaris. -The method to set the shared library search path varies between platforms, but -the most widely usable 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://www.visi.com/~barr/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 on 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 BSD/OS, Linux, or SunOS 4 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 every user): - - 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 a line -like the following to a shell start-up file unless you installed into a -location that is searched by default. - - MANPATH=/usr/local/pgsql/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 Administrator's Guide 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. The previous 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/postmaster -D /usr/local/pgsql/data - - This will start the server in the foreground. To put the server in the - background use something like - - nohup /usr/local/pgsql/bin/postmaster -D /usr/local/pgsql/data \ - >server.log 2>&1 or , not to the people listed here. - ________________________________________________________________________________ -|OS______|Processor__|Version|Reported_________________________|Remarks__________| -|AIX |RS6000 |7.3 |2002-11-12, Andreas Zeugswetter |see also doc/ | -|________|___________|_______|()______|FAQ_AIX__________| -|BSD/OS |x86 |7.3 |2002-10-25, Bruce Momjian |4.2 | -|________|___________|_______|()_______|_________________| -|FreeBSD |Alpha |7.3 |2002-11-13, Chris Kings-Lynne | | -|________|___________|_______|()__|_________________| -|FreeBSD |x86 |7.3 |2002-10-29, 3.3, Nigel J. Andrews| | -| | | |(),| | -| | | |4.7, Larry Rosenman | | -| | | |(), 5.0, Sean | | -| | | |Chittenden | | -|________|___________|_______|()__________|_________________| -|HP-UX |PA-RISC |7.3 |2002-10-28, 10.20 Tom Lane |gcc and cc; see | -| | | |(), 11.00, |also doc/FAQ_HPUX| -| | | |11.11, 32 & 64 bit, Giles Lean | | -|________|___________|_______|()_________|_________________| -|IRIX |MIPS |7.3 |2002-10-27, Ian Barwick |Irix64 Komma 6.5 | -|________|___________|_______|()______________|_________________| -|Linux |Alpha |7.3 |2002-10-28, Magnus Naeslund |2.4.19-pre6 | -|________|___________|_______|()_________________|_________________| -|Linux |armv4l |7.2 |2001-12-10, Mark Knox |2.2.x | -|________|___________|_______|()________|_________________| -|Linux |MIPS |7.2 |2001-11-15, Hisao Shibuya |2.0.x; Cobalt | -|________|___________|_______|()__________|Qube2____________| -|Linux |PlayStation|7.2 |2001-12-12, Permaine Cheung |#undef | -| |2 | |) |HAS_TEST_AND_SET,| -|________|___________|_______|_________________________________|slock_t__________| -|Linux |PPC74xx |7.3 |2002-10-26, Tom Lane |bye 2.2.18; Apple| -|________|___________|_______|()____________|G3_______________| -|Linux |S/390 |7.2 |2001-12-12, Permaine Cheung | | -|________|___________|_______|)____________|_________________| -|Linux |Sparc |7.3 |2002-10-26, Doug McNaught |3.0 | -|________|___________|_______|()____________|_________________| -|Linux |x86 |7.3 |2002-10-26, Alvaro Herrera |2.4 | -|________|___________|_______|()_______|_________________| -|MacOS X |PPC |7.3 |2002-10-28, 10.1, Tom Lane | | -| | | |(), 10.2.1, | | -| | | |Adam Witney | | -|________|___________|_______|()__________|_________________| -|NetBSD |Alpha |7.2 |2001-11-20, Thomas Thai |1.5W | -|________|___________|_______|()____________|_________________| -|NetBSD |arm32 |7.3 |2002-11-19, Patrick Welche |1.6 | -|________|___________|_______|()_________|_________________| -|NetBSD |m68k |7.0 |2000-04-10, Henry B. Hotz |Mac 8xx | -|________|___________|_______|()____________|_________________| -|NetBSD |MIPS |7.2.1 |2002-06-13, Warwick Hunter |1.5.3 | -|________|___________|_______|()_____________|_________________| -|NetBSD |PPC |7.2 |2001-11-28, Bill Studenmund |1.5 | -|________|___________|_______|()__________|_________________| -|NetBSD |Sparc |7.2 |2001-12-03, Matthew Green |32- and 64-bit | -|________|___________|_______|()____________|builds___________| -|NetBSD |VAX |7.1 |2001-03-30, Tom I. Helbekkmo |1.5 | -|________|___________|_______|()______________|_________________| -|NetBSD |x86 |7.3 |2002-11-14, Patrick Welche |1.6 | -|________|___________|_______|()_________|_________________| -|OpenBSD |Sparc |7.3 |2002-11-17, Christopher Kings- |3.2 | -| | | |Lynne | | -|________|___________|_______|()__|_________________| -|OpenBSD |x86 |7.3 |2002-11-14, 3.1 Magnus Naeslund | | -| | | |(), 3.2 Christopher| | -| | | |Kings-Lynne | | -|________|___________|_______|()__|_________________| -|Solaris |Sparc |7.3 |2002-10-28, Andrew Sullivan |Solaris 7 & 8; | -| | | |() |see also doc/ | -|________|___________|_______|_________________________________|FAQ_Solaris______| -|Solaris |x86 |7.2 |2001-11-28, Martin Renters |2.8; see also | -|________|___________|_______|()___________|doc/FAQ_Solaris__| -|SunOS 4 |Sparc |7.2 |2001-12-04, Tatsuo Ishii ()________________|_________________| -|Tru64 |Alpha |7.3 |2002-11-05, Alessio Bragadini | | -|UNIX____|___________|_______|()_________|_________________| -|UnixWare|x86 |7.3 |2002-11-01, 7.1.3 Larry Rosenman |see also doc/ | -| | | |(), 7.1.1 and |FAQ_SCO | -| | | |7.1.2(8.0.0) Olivier Prenant | | -|________|___________|_______|()_______________|_________________| -|Windows |x86 |7.3 |2002-10-29, Dave Page |with Cygwin; see | -| | | |(), |doc/FAQ_MSWIN | -| | | |Jason Tishler | | -|________|___________|_______|()____________|_________________| -|Windows |x86 |7.3 |2002-11-05, Dave Page |native is client-| -| | | |() |side only; see | -| | | | |Administrator's | -|________|___________|_______|_________________________________|Guide____________| - -Unsupported Platforms: The following platforms are either known not to work, or -they used to work in a previous release and we did not receive explicit -confirmation of a successful test with version 7.3 at the time this list was -compiled. We include these here to let you know that these platforms *could* be -supported if given some attention. - _____________________________________________________________________________ -|OS__________|Processor|Version|Reported_______________________|Remarks_______| -|BeOS |x86 |7.2 |2001-11-29, Cyril Velter |needs updates | -| | | |()|to semaphore | -|____________|_________|_______|_______________________________|code__________| -|DG/UX |m88k |6.3 |1998-03-01, Brian E Gallew |no recent | -|5.4R4.11____|_________|_______|()______________|reports_______| -|MkLinux DR1 |PPC750 |7.0 |2001-04-03, Tatsuo Ishii ()______________|update?_______| -|NeXTSTEP |x86 |6.x |1998-03-01, David Wetzel |bit rot | -|____________|_________|_______|()___________|suspected_____| -|QNX 4 RTOS |x86 |7.2 |2001-12-10, Bernd Tegge |needs updates | -| | | |() |to semaphore | -| | | | |code; see also| -|____________|_________|_______|_______________________________|doc/FAQ_QNX4__| -|QNX RTOS v6 |x86 |7.2 |2001-11-20, Igor Kovalenko |patches | -| | | |()|available in | -| | | | |archives, but | -| | | | |too late for | -|____________|_________|_______|_______________________________|7.2___________| -|SCO |x86 |6.5 |1999-05-25, Andrew Merrill |7.2 should | -|OpenServer 5| | |() |work, but no | -| | | | |reports; see | -| | | | |also doc/ | -|____________|_________|_______|_______________________________|FAQ_SCO_______| -|System V R4 |m88k |6.2.1 |1998-03-01, Doug Winterburn |needs new TAS | -|____________|_________|_______|()______|spinlock_code_| -|System V R4 |MIPS |6.4 |1998-10-28, Frank Ridderbusch |no recent | -|____________|_________|_______|()_____|reports_______| -|Ultrix |MIPS |7.1 |2001-03-26 |TAS spinlock | -| | | | |code not | -|____________|_________|_______|_______________________________|detected______| -|Ultrix______|VAX______|6.x____|1998-03-01_____________________|______________| - + 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 will work only if + you use GCC. + + If you prefer a C compiler different from the one "configure" + picks then you can set the environment variable CC to the program + of your choice. By default, "configure" will pick "gcc" unless + this is inappropriate for the platform. Similarly, you can + override the default compiler flags with the CFLAGS variable. + You can specify environment variables on the "configure" command + line, for example: +./configure CC=/opt/bin/gcc CFLAGS='-O2 -pipe' + 2. Build + To start the build, type +gmake + (Remember to use GNU make.) The build may take anywhere from 5 + minutes to half an hour depending on your hardware. The last line + displayed should be +All of PostgreSQL is successfully made. Ready to install. + 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 +gmake check + (This won't work as root; do it as an unprivileged user.) It is + possible that some tests fail, due to differences in error message + wording or floating point results. The file + "src/test/regress/README" and the documentation contain 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 and are going to + install the new files over the old ones, then you should have + backed up your data and shut down the old server by now, as + explained in the section called If You Are Upgrading above. + To install PostgreSQL enter +gmake 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 could create the target directories in advance + and arrange for appropriate permissions to be granted. + You can use gmake install-strip instead of gmake 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 only the header files needed + for client application development. If you plan to do any + server-side program development (such as custom functions or data + types written in C), then you may want to install the entire + PostgreSQL include tree into your target include directory. To do + that, enter +gmake install-all-headers + This adds a megabyte or two to the installation footprint, and is + only useful if you don't plan to keep the whole source tree around + for reference. (If you do, you can just use the source's include + directory when building server-side software.) + Client-only installation: If you want to install only the client + applications and interface libraries, then you can use these + commands: +gmake -C src/bin install +gmake -C src/include install +gmake -C src/interfaces install +gmake -C doc install + + Uninstallation: To undo the installation use the command "gmake + uninstall". However, this will not remove any created directories. + + Cleaning: After the installation you can make room by removing the + built files from the source tree with the command "gmake clean". This + will preserve the files made by the "configure" program, so that you + can rebuild everything with "gmake" later on. To reset the source tree + to the state in which it was distributed, use "gmake distclean". If + you are going to build for several platforms from the same source tree + you must do this and re-configure for each build. + + 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 "gmake + distclean" before reconfiguring and rebuilding. Without this, your + changes in configuration choices may not propagate everywhere they + need to. + _________________________________________________________________ + + Post-Installation Setup + + Tuning + + By default, PostgreSQL is configured to run on minimal hardware. This + allows it to start up with almost any hardware configuration. However, + the default configuration is not designed for optimum performance. To + achieve optimum performance, several server variables must be + adjusted, the two most common being shared_buffers and sort_mem + mentioned in the documentation . Other parameters in the documentation + also affect performance. + _________________________________________________________________ + + Shared Libraries + + On some systems that have shared libraries (which most systems do) you + need to tell your system how to find the newly installed shared + libraries. The systems on which this is *not* necessary include + BSD/OS, FreeBSD, HP-UX, IRIX, Linux, NetBSD, OpenBSD, Tru64 UNIX + (formerly Digital UNIX), and Solaris. + + The method to set the shared library search path varies between + platforms, but the most widely usable 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://www.visi.com/~barr/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 on 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 BSD/OS, Linux, or SunOS 4 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 every + user): +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/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. The previous 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/postmaster -D /usr/local/pgsql/data + This will start the server in the foreground. To put the server in + the background use something like +nohup /usr/local/pgsql/bin/postmaster -D /usr/local/pgsql/data \ + >server.log 2>&1 or + , not to the people listed here. + + OS Processor Version Reported Remarks + AIX RS6000 7.3 2002-11-12, Andreas Zeugswetter + () see also doc/FAQ_AIX + BSD/OS x86 7.3 2002-10-25, Bruce Momjian () + 4.2 + FreeBSD Alpha 7.3 2002-11-13, Chris Kings-Lynne + () + FreeBSD x86 7.3 2002-10-29, 3.3, Nigel J. Andrews + (), 4.7, Larry Rosenman + (), 5.0, Sean Chittenden () + HP-UX PA-RISC 7.3 2002-10-28, 10.20 Tom Lane (), + 11.00, 11.11, 32 and 64 bit, Giles Lean () gcc + and cc; see also doc/FAQ_HPUX + IRIX MIPS 7.3 2002-10-27, Ian Barwick () Irix64 Komma + 6.5 + Linux Alpha 7.3 2002-10-28, Magnus Naeslund () + 2.4.19-pre6 + Linux armv4l 7.2 2001-12-10, Mark Knox () 2.2.x + Linux MIPS 7.2 2001-11-15, Hisao Shibuya () + 2.0.x; Cobalt Qube2 + Linux PlayStation 2 7.3 2002-11-19, Permaine Cheung + ) #undef HAS_TEST_AND_SET, remove slock_t typedef + Linux PPC74xx 7.3 2002-10-26, Tom Lane () bye + 2.2.18; Apple G3 + Linux S/390 7.3 2002-11-22, Permaine Cheung ) both + s390 and s390x (32 and 64 bit) + Linux Sparc 7.3 2002-10-26, Doug McNaught () 3.0 + Linux x86 7.3 2002-10-26, Alvaro Herrera () + 2.4 + MacOS X PPC 7.3 2002-10-28, 10.1, Tom Lane (), + 10.2.1, Adam Witney () + NetBSD Alpha 7.2 2001-11-20, Thomas Thai () 1.5W + NetBSD arm32 7.3 2002-11-19, Patrick Welche () + 1.6 + NetBSD m68k 7.0 2000-04-10, Henry B. Hotz () Mac + 8xx + NetBSD MIPS 7.2.1 2002-06-13, Warwick Hunter () + 1.5.3 + NetBSD PPC 7.2 2001-11-28, Bill Studenmund () 1.5 + NetBSD Sparc 7.2 2001-12-03, Matthew Green () 32- + and 64-bit builds + NetBSD VAX 7.1 2001-03-30, Tom I. Helbekkmo () 1.5 + NetBSD x86 7.3 2002-11-14, Patrick Welche () 1.6 + OpenBSD Sparc 7.3 2002-11-17, Christopher Kings-Lynne + () 3.2 + OpenBSD x86 7.3 2002-11-14, 3.1 Magnus Naeslund (), 3.2 + Christopher Kings-Lynne () + SCO OpenServer 5 x86 7.3.1 2002-12-11, Shibashish Satpathy + () 5.0.4, gcc; see also doc/FAQ_SCO + Solaris Sparc 7.3 2002-10-28, Andrew Sullivan + () Solaris 7 and 8; see also doc/FAQ_Solaris + Solaris x86 7.3 2002-11-20, Martin Renters () 5.8; + see also doc/FAQ_Solaris + SunOS 4 Sparc 7.2 2001-12-04, Tatsuo Ishii () + Tru64 UNIX Alpha 7.3 2002-11-05, Alessio Bragadini + () + UnixWare x86 7.3 2002-11-01, 7.1.3 Larry Rosenman (), + 7.1.1 and 7.1.2(8.0.0) Olivier Prenant () see also + doc/FAQ_SCO + Windows x86 7.3 2002-10-29, Dave Page (), + Jason Tishler () with Cygwin; see doc/FAQ_MSWIN + Windows x86 7.3 2002-11-05, Dave Page () + native is client-side only; see documentation + + Unsupported Platforms: The following platforms are either known not to + work, or they used to work in a previous release and we did not + receive explicit confirmation of a successful test with version 7.4 at + the time this list was compiled. We include these here to let you know + that these platforms *could* be supported if given some attention. + + OS Processor Version Reported Remarks + BeOS x86 7.2 2001-11-29, Cyril Velter () + needs updates to semaphore code + DG/UX 5.4R4.11 m88k 6.3 1998-03-01, Brian E Gallew () + no recent reports + MkLinux DR1 PPC750 7.0 2001-04-03, Tatsuo Ishii () + 7.1 needs OS update? + NeXTSTEP x86 6.x 1998-03-01, David Wetzel () bit rot + suspected + QNX 4 RTOS x86 7.2 2001-12-10, Bernd Tegge () + needs updates to semaphore code; see also doc/FAQ_QNX4 + QNX RTOS v6 x86 7.2 2001-11-20, Igor Kovalenko + () patches available in archives, but too + late for 7.2 + System V R4 m88k 6.2.1 1998-03-01, Doug Winterburn + () needs new TAS spinlock code + System V R4 MIPS 6.4 1998-10-28, Frank Ridderbusch + () no recent reports + Ultrix MIPS 7.1 2001-03-26 TAS spinlock code not detected + Ultrix VAX 6.x 1998-03-01 diff --git a/doc/src/sgml/installation.sgml b/doc/src/sgml/installation.sgml index 92eb827547..e8e9253671 100644 --- a/doc/src/sgml/installation.sgml +++ b/doc/src/sgml/installation.sgml @@ -1,4 +1,4 @@ - + <![%standalone-include[<productname>PostgreSQL</>]]> @@ -1169,9 +1169,11 @@ All of PostgreSQL is successfully made. Ready to install. optimum performance. To achieve optimum performance, several server variables must be adjusted, the two most common being <varname>shared_buffers</varname> and <varname> sort_mem</varname> - mentioned in <xref linkend="runtime-config-resource-memory">. Other - parameters in <xref linkend="runtime-config-resource"> also affect - performance. + mentioned in <![%standalone-include[the documentation]]> + <![%standalone-ignore[<xref linkend="runtime-config-resource-memory">]]>. + Other parameters in <![%standalone-include[the documentation]]> + <![%standalone-ignore[<xref linkend="runtime-config-resource">]]> + also affect performance. </para> </sect2> -- 2.40.0