diff --git a/doc/src/sgml/install-win32.sgml b/doc/src/sgml/install-win32.sgml index 4afff62dc1..acbfa2bb12 100644 --- a/doc/src/sgml/install-win32.sgml +++ b/doc/src/sgml/install-win32.sgml @@ -1,9 +1,9 @@ - Client-Only Installation on <productname>Windows</productname> + Installation on <productname>Windows</productname> installation @@ -12,9 +12,8 @@ $PostgreSQL: pgsql/doc/src/sgml/install-win32.sgml,v 1.19 2004/12/24 18:32:50 mo Although PostgreSQL is written for - Unix-like operating systems and can be built using - MinGW and - Cygwin, the C client library + Unix-like operating systems and compiles under + MinGW, the C client library (libpq) and the interactive terminal (psql) can be compiled using other Windows tool sets. Makefiles are included in the source distribution for diff --git a/doc/src/sgml/installation.sgml b/doc/src/sgml/installation.sgml index 7149198248..efab42f319 100644 --- a/doc/src/sgml/installation.sgml +++ b/doc/src/sgml/installation.sgml @@ -1,1883 +1,1876 @@ - - - - <![%standalone-include[<productname>PostgreSQL</>]]> - Installation Instructions - - - installation - - - - This - 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 - - - - - - - - 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 - 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: - - - - - - make - - - 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. - - - - - - - readline - - - 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 option for - configure. (On NetBSD, - the libedit library is - Readline-compatible and is used if - libreadline is not found.) - - - - - - - installation - on Windows - - - To build on NT-based versions of - Windows like Windows XP and 2003 see - doc/FAQ_MINGW. For earlier Windows - releases see doc/FAQ_CYGWIN. - - To build Windows client-only interfaces using - tools like Visual C++ and Borland - C++ see - ]]>. - - - - - - - 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 - 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 with the header files and the distutils module. - The distutils module is included by default with - Python 1.6 and later; users of - earlier versions of Python will need - to install it. - - - - Since PL/Python will be a shared - library, the libpython - 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. - - - - If you have problems, run Python 2.3 or later's - configure using the --enable-shared flag. On some - operating systems you don't have to build a shared library, but - 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 the PL/Tcl - procedural language, you of course need a Tcl installation. - - - - - - 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: . - 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 - - - bison - - - yacc - - - 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 - for a list) or at . - - - - 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. - - - - - Getting The Source - - - The PostgreSQL &version; sources can be obtained by - anonymous FTP from . - Use a mirror if possible. After you have obtained the file, unpack it: - -gunzip postgresql-&version;.tar.gz -tar xf postgresql-&version;.tar - - This will create a directory - postgresql-&version; under the current directory - with the PostgreSQL sources. - Change into that directory for the rest - of the installation procedure. - - -]]> - - - If You Are Upgrading - - - 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 - &majorversion;.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. - - - - - - 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. - - - - - - - pg_dumpall - use during upgrade - - - 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 option when running - pg_dumpall. - - - - pg_dumpall does not - save large objects. Check - - ]]> - 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 &version;, - 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. - - - - - - 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 | sed 1q` - - 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. - - - - - - 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 &version;, 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 ,]]> which you are encouraged to read in any - case. - - - - - - Installation Procedure - - - - - Configuration</> - - <indexterm zone="configure"> - <primary>configure</primary> - </indexterm> - - <para> - 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 <filename>configure</> script. For a - default installation simply enter -<screen> -<userinput>./configure</userinput> -</screen> - 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 - <filename>configure</filename> in a directory outside the source - tree if you want to keep the build directory separate.) - </para> - - <para> - 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 - <filename>/usr/local/pgsql</> by default. - </para> - - <para> - You can customize the build and installation process by supplying one - or more of the following command line options to - <filename>configure</filename>: - - <variablelist> - <varlistentry> - <term><option>--prefix=<replaceable>PREFIX</></option></term> - <listitem> - <para> - Install all files under the directory <replaceable>PREFIX</> - instead of <filename>/usr/local/pgsql</filename>. The actual - files will be installed into various subdirectories; no files - will ever be installed directly into the - <replaceable>PREFIX</> directory. - </para> - - <para> - If you have special needs, you can also customize the - individual subdirectories with the following options. However, - if you leave these with their defaults, the installation will be - relocatable, meaning you can move the directory after - installation. (The <literal>man</> and <literal>doc</> - locations are not affected by this.) - </para> - - <para> - For relocatable installs, you might want to use - <filename>configure</filename>'s <literal>--disable-rpath</> - option. Also, you will need to tell the operating system how - to find the shared libraries. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term><option>--exec-prefix=<replaceable>EXEC-PREFIX</></option></term> - <listitem> - <para> - You can install architecture-dependent files under a - different prefix, <replaceable>EXEC-PREFIX</>, than what - <replaceable>PREFIX</> was set to. This can be useful to - share architecture-independent files between hosts. If you - omit this, then <replaceable>EXEC-PREFIX</> is set equal to - <replaceable>PREFIX</> and both architecture-dependent and - independent files will be installed under the same tree, - which is probably what you want. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term><option>--bindir=<replaceable>DIRECTORY</></option></term> - <listitem> - <para> - Specifies the directory for executable programs. The default - is <filename><replaceable>EXEC-PREFIX</>/bin</>, which - normally means <filename>/usr/local/pgsql/bin</>. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term><option>--datadir=<replaceable>DIRECTORY</></option></term> - <listitem> - <para> - Sets the directory for read-only data files used by the - installed programs. The default is - <filename><replaceable>PREFIX</>/share</>. Note that this has - nothing to do with where your database files will be placed. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term><option>--sysconfdir=<replaceable>DIRECTORY</></option></term> - <listitem> - <para> - The directory for various configuration files, - <filename><replaceable>PREFIX</>/etc</> by default. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term><option>--libdir=<replaceable>DIRECTORY</></option></term> - <listitem> - <para> - The location to install libraries and dynamically loadable - modules. The default is - <filename><replaceable>EXEC-PREFIX</>/lib</>. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term><option>--includedir=<replaceable>DIRECTORY</></option></term> - <listitem> - <para> - The directory for installing C and C++ header files. The - default is <filename><replaceable>PREFIX</>/include</>. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term><option>--mandir=<replaceable>DIRECTORY</></option></term> - <listitem> - <para> - The man pages that come with <productname>PostgreSQL</> will be installed under - this directory, in their respective - <filename>man<replaceable>x</></> subdirectories. - The default is <filename><replaceable>PREFIX</>/man</>. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term><option>--with-docdir=<replaceable>DIRECTORY</></option></term> - <term><option>--without-docdir</option></term> - <listitem> - <para> - Documentation files, except <quote>man</> pages, will be - installed into this directory. The default is - <filename><replaceable>PREFIX</>/doc</>. If the option - <option>--without-docdir</option> is specified, the - documentation will not be installed by <command>make - install</command>. This is intended for packaging scripts - that have special methods for installing documentation. - </para> - </listitem> - </varlistentry> - </variablelist> - - <note> - <para> - Care has been taken to make it possible to install - <productname>PostgreSQL</> into shared installation locations - (such as <filename>/usr/local/include</filename>) without - interfering with the namespace of the rest of the system. First, - the string <quote><literal>/postgresql</literal></quote> is - automatically appended to <varname>datadir</varname>, - <varname>sysconfdir</varname>, and <varname>docdir</varname>, - unless the fully expanded directory name already contains the - string <quote><literal>postgres</></quote> or - <quote><literal>pgsql</></quote>. For example, if you choose - <filename>/usr/local</filename> as prefix, the documentation will - be installed in <filename>/usr/local/doc/postgresql</filename>, - but if the prefix is <filename>/opt/postgres</filename>, then it - will be in <filename>/opt/postgres/doc</filename>. The public C - header files of the client interfaces are installed into - <varname>includedir</varname> and are namespace-clean. The - internal header files and the server header files are installed - into private directories under <varname>includedir</varname>. 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 <varname>libdir</varname> - for dynamically loadable modules. - </para> - </note> - </para> - - <para> - <variablelist> - <varlistentry> - <term><option>--with-includes=<replaceable>DIRECTORIES</></option></term> - <listitem> - <para> - <replaceable>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 <application>Readline</>) installed in a non-standard - location, - you have to use this option and probably also the corresponding - <option>--with-libraries</> option. - </para> - <para> - Example: <literal>--with-includes=/opt/gnu/include:/usr/sup/include</>. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term><option>--with-libraries=<replaceable>DIRECTORIES</></option></term> - <listitem> - <para> - <replaceable>DIRECTORIES</> is a colon-separated list of - directories to search for libraries. You will probably have - to use this option (and the corresponding - <option>--with-includes</> option) if you have packages - installed in non-standard locations. - </para> - <para> - Example: <literal>--with-libraries=/opt/gnu/lib:/usr/sup/lib</>. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term><option>--enable-nls<optional>=<replaceable>LANGUAGES</replaceable></optional></option></term> - <listitem> - <para> - Enables Native Language Support (<acronym>NLS</acronym>), - that is, the ability to display a program's messages in a - language other than English. - <replaceable>LANGUAGES</replaceable> is a space separated - list of codes of the languages that you want supported, for - example <literal>--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. - </para> - - <para> - To use this option, you will need an implementation of the - <application>Gettext</> API; see above. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term><option>--with-pgport=<replaceable>NUMBER</></option></term> - <listitem> - <para> - Set <replaceable>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 - <productname>PostgreSQL</> servers on the same machine. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term><option>--with-perl</option></term> - <listitem> - <para> - Build the <application>PL/Perl</> server-side language. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term><option>--with-python</option></term> - <listitem> - <para> - Build the <application>PL/Python</> server-side language. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term><option>--with-tcl</option></term> - <listitem> - <para> - Build the <application>PL/Tcl</> server-side language. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term><option>--with-tclconfig=<replaceable>DIRECTORY</replaceable></option></term> - <listitem> - <para> - Tcl installs the file <filename>tclConfig.sh</filename>, 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 it. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term><option>--with-krb4</option></term> - <term><option>--with-krb5</option></term> - <listitem> - <para> - Build with support for Kerberos authentication. You can use - either Kerberos version 4 or 5, but not both. On many - systems, the Kerberos system is not installed in a location - that is searched by default (e.g., <filename>/usr/include</>, - <filename>/usr/lib</>), so you must use the options - <option>--with-includes</> and <option>--with-libraries</> in - addition to this option. <filename>configure</> will check - for the required header files and libraries to make sure that - your Kerberos installation is sufficient before proceeding. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term><option>--with-krb-srvnam=<replaceable>NAME</></option></term> - <listitem> - <para> - The name of the Kerberos service principal. - <literal>postgres</literal> is the default. There's probably no - reason to change this. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <indexterm> - <primary>OpenSSL</primary> - <seealso>SSL</seealso> - </indexterm> - - <term><option>--with-openssl</option></term> - <listitem> - <para> - Build with support for <acronym>SSL</> (encrypted) - connections. This requires the <productname>OpenSSL</> - package to be installed. <filename>configure</> will check - for the required header files and libraries to make sure that - your <productname>OpenSSL</> installation is sufficient - before proceeding. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term><option>--with-pam</option></term> - <listitem> - <para> - Build with <acronym>PAM</><indexterm><primary>PAM</></> - (Pluggable Authentication Modules) support. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term><option>--without-readline</option></term> - <listitem> - <para> - Prevents the use of the <application>Readline</> library. This disables - command-line editing and history in - <application>psql</application>, so it is not recommended. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term><option>--with-rendezvous</option></term> - <listitem> - <para> - Build with Rendezvous support. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term><option>--disable-spinlocks</option></term> - <listitem> - <para> - Allow the build to succeed even if <productname>PostgreSQL</> - has no CPU spinlock support for the platform. The lack of - spinlock support will result in 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 <productname>PostgreSQL</> on - your platform, please report the problem to the - <productname>PostgreSQL</> developers. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term><option>--enable-thread-safety</option></term> - <listitem> - <para> - Make the client libraries thread-safe. This allows - concurrent threads in <application>libpq</application> and - <application>ECPG</application> programs to safely control - their private connection handles. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term><option>--without-zlib</option></term> - <listitem> - <para> - Prevents the use of the <application>Zlib</> library. This disables - compression support in <application>pg_dump</application>. - This option is only intended for those rare systems where this - library is not available. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term><option>--enable-debug</option></term> - <listitem> - <para> - 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. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term><option>--enable-cassert</option></term> - <listitem> - <para> - Enables <firstterm>assertion</> checks in the server, which test for - many <quote>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. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term><option>--enable-depend</option></term> - <listitem> - <para> - 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. - </para> - </listitem> - </varlistentry> - - </variablelist> - </para> - - <para> - If you prefer a C compiler different from the one - <filename>configure</filename> picks then you can set the - environment variable <envar>CC</> to the program of your choice. - By default, <filename>configure</filename> will pick - <filename>gcc</filename> unless this is inappropriate for the - platform. Similarly, you can override the default compiler flags - with the <envar>CFLAGS</envar> variable. - </para> - - <para> - You can specify environment variables on the - <filename>configure</filename> command line, for example: -<screen> -<userinput>./configure CC=/opt/bin/gcc CFLAGS='-O2 -pipe'</> -</screen> - </para> - </step> - - <step> - <title>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. - - - - - - Regression Tests - - - regression test - - - - 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.) - src/test/regress/README and the - documentation contain]]> - contains]]> - detailed information about interpreting the test results. You can - repeat this test at any later time by issuing the same command. - - - - - Installing The Files - - - - 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 - above. - - - - - To install PostgreSQL enter - -gmake install - - This will install files into the directories that were specified - in . 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 all the header files needed for client - application development as well as for any 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: - -gmake -C src/bin install -gmake -C src/include install -gmake -C src/interfaces install -gmake -C doc install - - - - - - - - Registering <application>eventlog</> on <systemitem - class="osname">Windows</>: - - To register a Windows eventlog - library with the operating system, issue this command after installation: - -regsvr32 pgsql_library_directory/pgevent.dll - - This creates registry entries used by the event viewer. - - - - - 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 - - - shared library - - - - 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 - - - - 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. - - - - - ldconfig - - 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 - - - PATH - - - - 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 - - - - 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 ) - - - - - - MANPATH - - 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. - - - - - - 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 - - - - - - - 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 - - - - - 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 \ - </dev/null >>server.log 2>&1 </dev/null & - - - - - To stop a server running in the background you can type - -kill `cat /usr/local/pgsql/data/postmaster.pid` - - - - - In order to allow TCP/IP connections (rather than only Unix - domain socket ones) you need to pass the - - - - - Create a database: - -createdb testdb - - Then enter - -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 - gmake 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 - - - PostgreSQL has been verified by the developer - community to work on the platforms listed below. A supported - platform generally means that PostgreSQL builds and - installs according to these instructions and that the regression - tests pass. Build farm entries refer to builds - reported by the PostgreSQL - Build Farm. - - - - - If you are having problems with the installation on a supported - platform, please write to pgsql-bugs@postgresql.org - or pgsql-ports@postgresql.org, not to the people - listed here. - - - - - - - - OS - Processor - Version - Reported - Remarks - - - - - AIX - PowerPC - 8.0.0 - Travis P (twp@castle.fastmail.fm), 2004-12-12 - see also doc/FAQ_AIX - - - AIX - RS6000 - 8.0.0 - Hans-Jürgen Schönig (hs@cybertec.at), 2004-12-06 - see also doc/FAQ_AIX - - - BSD/OS - x86 - 8.0.0 - Bruce Momjian (pgman@candle.pha.pa.us), 2004-12-07 - 4.3.1 - - - Debian GNU/Linux - Alpha - 7.4 - Noèl Köthe (noel@debian.org), 2003-10-25 - - - - Debian GNU/Linux - AMD64 - 8.0.0 - Build farm panda, snapshot 2004-12-06 01:20:02 - sid, kernel 2.6 - - - Debian GNU/Linux - arm41 - 7.4 - Noèl Köthe (noel@debian.org), 2003-10-25 - - - - Debian GNU/Linux - Itanium - 7.4 - Noèl Köthe (noel@debian.org), 2003-10-25 - - - - Debian GNU/Linux - m68k - 8.0.0 - Noèl Köthe (noel@debian.org), 2004-12-09 - sid - - - Debian GNU/Linux - MIPS - 8.0.0 - Build farm lionfish, snapshot 2004-12-06 11:00:08 - 3.1 (sarge), kernel 2.4 - - - Debian GNU/Linux - PA-RISC - 8.0.0 - Noèl Köthe (noel@debian.org), 2004-12-07 - - - - Debian GNU/Linux - PowerPC - 8.0.0 - Noèl Köthe (noel@debian.org), 2004-12-15 - - - - Debian GNU/Linux - S/390 - 7.4 - Noèl Köthe (noel@debian.org), 2003-10-25 - - - - Debian GNU/Linux - Sparc - 8.0.0 - Noèl Köthe (noel@debian.org), 2004-12-09 - sid, 32-bit - - - Debian GNU/Linux - x86 - 8.0.0 - Peter Eisentraut (peter_e@gmx.net), 2004-12-06 - 3.1 (sarge), kernel 2.6 - - - Fedora - AMD64 - 8.0.0 - John Gray (jgray@azuli.co.uk), 2004-12-12 - FC3 - - - Fedora - x86 - 8.0.0 - Build farm dog, snapshot 2004-12-06 02:06:01 - FC1 - - - FreeBSD - Alpha - 7.4 - Peter Eisentraut (peter_e@gmx.net), 2003-10-25 - 4.8 - - - FreeBSD - x86 - 8.0.0 - Build farm cockatoo, snapshot 2004-12-06 14:10:01 (4.10); - Marc Fournier (scrappy@postgresql.org), 2004-12-07 (5.3) - - - - Gentoo Linux - x86 - 8.0.0 - Paul Bort (pbort@tmwsystems.com), 2004-12-07 - - - - HP-UX - PA-RISC - 7.4 - - Tom Lane (tgl@sss.pgh.pa.us), 2003-10-31 (10.20); - Peter Eisentraut (peter_e@gmx.net), 2003-11-04 (11.00) - - gcc and cc; see also doc/FAQ_HPUX - - - IRIX - MIPS - 7.4 - Robert E. Bruccoleri (bruc@stone.congenomics.com), 2003-11-12 - 6.5.20, cc only - - - Mac OS X - PowerPC - 8.0.0 - Andrew Rawnsley (ronz@ravensfield.com), 2004-12-07 - 10.3.5 - - - Mandrakelinux - x86 - 8.0.0 - Build farm shrew, snapshot 2004-12-06 02:02:01 - 10.0 - - - NetBSD - arm32 - 7.4 - Patrick Welche (prlw1@newn.cam.ac.uk), 2003-11-12 - 1.6ZE/acorn32 - - - NetBSD - Sparc - 7.4.1 - Peter Eisentraut (peter_e@gmx.net), 2003-11-26 - 1.6.1, 32-bit - - - NetBSD - x86 - 8.0.0 - Build farm canary, snapshot 2004-12-06 03:30:00 - 1.6 - - - OpenBSD - Sparc - 7.4 - Peter Eisentraut (peter_e@gmx.net), 2003-11-01 - 3.4 - - - OpenBSD - x86 - 8.0.0 - Build farm emu, snapshot 2004-12-06 11:35:03 - 3.6 - - - Red Hat Linux - AMD64 - 8.0.0 - Tom Lane (tgl@sss.pgh.pa.us), 2004-12-07 - RHEL 3AS - - - Red Hat Linux - IA64 - 8.0.0 - Tom Lane (tgl@sss.pgh.pa.us), 2004-12-07 - RHEL 3AS - - - Red Hat Linux - PowerPC - 8.0.0 - Tom Lane (tgl@sss.pgh.pa.us), 2004-12-07 - RHEL 3AS - - - Red Hat Linux - PowerPC 64 - 8.0.0 - Tom Lane (tgl@sss.pgh.pa.us), 2004-12-07 - RHEL 3AS - - - Red Hat Linux - S/390 - 8.0.0 - Tom Lane (tgl@sss.pgh.pa.us), 2004-12-07 - RHEL 3AS - - - Red Hat Linux - S/390x - 8.0.0 - Tom Lane (tgl@sss.pgh.pa.us), 2004-12-07 - RHEL 3AS - - - Red Hat Linux - x86 - 8.0.0 - Tom Lane (tgl@sss.pgh.pa.us), 2004-12-07 - RHEL 3AS - - - Solaris - Sparc - 8.0.0 - Kenneth Marshall (ktm@is.rice.edu), 2004-12-07 - Solaris 8; see also doc/FAQ_Solaris - - - Solaris - x86 - 8.0.0 - Build farm kudu, snapshot 2004-12-10 02:30:04 (cc); - dragonfly, snapshot 2004-12-09 04:30:00 (gcc) - Solaris 9; see also doc/FAQ_Solaris - - - Tru64 UNIX - Alpha - 7.4 - Peter Eisentraut (peter_e@gmx.net), 2003-10-25 (5.1b); - Alessio Bragadini (alessio@albourne.com), 2003-10-29 (4.0g) - - - - UnixWare - x86 - 8.0.0 - Peter Eisentraut (peter_e@gmx.net), 2004-12-14 - cc, 7.1.4; see also doc/FAQ_SCO - - - Windows - x86 - 8.0.0 - Dave Page (dpage@vale-housing.co.uk), 2004-12-07 - see doc/FAQ_MINGW - - - Windows with Cygwin - x86 - 8.0.0 - Build farm gibbon, snapshot 2004-12-11 01:33:01 - see doc/FAQ_CYGWIN - - - - - - - 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 &majorversion; 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 (cyril.velter@libertysurf.fr) - needs updates to semaphore code - - - Linux - PlayStation 2 - 7.4 - 2003-11-02, - Peter Eisentraut (peter_e@gmx.net) - - needs new config.guess, - - - - - NetBSD - Alpha - 7.2 - 2001-11-20, - Thomas Thai (tom@minnesota.com) - 1.5W - - - NetBSD - MIPS - 7.2.1 - 2002-06-13, - Warwick Hunter (whunter@agile.tv) - 1.5.3 - - - NetBSD - PowerPC - 7.2 - 2001-11-28, - Bill Studenmund (wrstuden@netbsd.org) - 1.5 - - - NetBSD - VAX - 7.1 - 2001-03-30, - Tom I. Helbekkmo (tih@kpnQwest.no) - 1.5 - - - QNX 4 RTOS - x86 - 7.2 - 2001-12-10, - Bernd Tegge (tegge@repas-aeg.de) - - needs updates to semaphore code; - see also doc/FAQ_QNX4 - - - QNX RTOS v6 - x86 - 7.2 - 2001-11-20, Igor Kovalenko (Igor.Kovalenko@motorola.com) - patches available in archives, but too late for 7.2 - - - SCO OpenServer - x86 - 7.3.1 - 2002-12-11, - Shibashish Satpathy (shib@postmark.net) - 5.0.4, gcc; see also doc/FAQ_SCO - - - SunOS 4 - Sparc - 7.2 - 2001-12-04, Tatsuo Ishii (t-ishii@sra.co.jp) - - - - - - - - - - + + + + <![%standalone-include[<productname>PostgreSQL</>]]> + Installation Instructions + + + installation + + + + This + 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 + + + + + + + + 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 + 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: + + + + + + make + + + 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. + + + + + + + readline + + + 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 option for + configure. (On NetBSD, + the libedit library is + Readline-compatible and is used if + libreadline is not found.) + + + + + + + installation + on Windows + + + 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 + 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 with the header files and the distutils module. + The distutils module is included by default with + Python 1.6 and later; users of + earlier versions of Python will need + to install it. + + + + Since PL/Python will be a shared + library, the libpython + 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. + + + + If you have problems, run Python 2.3 or later's + configure using the --enable-shared flag. On some + operating systems you don't have to build a shared library, but + 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 the PL/Tcl + procedural language, you of course need a Tcl installation. + + + + + + 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: . + 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 + + + bison + + + yacc + + + 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 + for a list) or at . + + + + 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. + + + + + Getting The Source + + + The PostgreSQL &version; sources can be obtained by + anonymous FTP from . + Use a mirror if possible. After you have obtained the file, unpack it: + +gunzip postgresql-&version;.tar.gz +tar xf postgresql-&version;.tar + + This will create a directory + postgresql-&version; under the current directory + with the PostgreSQL sources. + Change into that directory for the rest + of the installation procedure. + + +]]> + + + If You Are Upgrading + + + 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 + &majorversion;.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. + + + + + + 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. + + + + + + + pg_dumpall + use during upgrade + + + 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 option when running + pg_dumpall. + + + + pg_dumpall does not + save large objects. Check + + ]]> + 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 &version;, + 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. + + + + + + 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 | sed 1q` + + 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. + + + + + + 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 &version;, 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 ,]]> which you are encouraged to read in any + case. + + + + + + Installation Procedure + + + + + Configuration</> + + <indexterm zone="configure"> + <primary>configure</primary> + </indexterm> + + <para> + 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 <filename>configure</> script. For a + default installation simply enter +<screen> +<userinput>./configure</userinput> +</screen> + 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 + <filename>configure</filename> in a directory outside the source + tree if you want to keep the build directory separate.) + </para> + + <para> + 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 + <filename>/usr/local/pgsql</> by default. + </para> + + <para> + You can customize the build and installation process by supplying one + or more of the following command line options to + <filename>configure</filename>: + + <variablelist> + <varlistentry> + <term><option>--prefix=<replaceable>PREFIX</></option></term> + <listitem> + <para> + Install all files under the directory <replaceable>PREFIX</> + instead of <filename>/usr/local/pgsql</filename>. The actual + files will be installed into various subdirectories; no files + will ever be installed directly into the + <replaceable>PREFIX</> directory. + </para> + + <para> + If you have special needs, you can also customize the + individual subdirectories with the following options. However, + if you leave these with their defaults, the installation will be + relocatable, meaning you can move the directory after + installation. (The <literal>man</> and <literal>doc</> + locations are not affected by this.) + </para> + + <para> + For relocatable installs, you might want to use + <filename>configure</filename>'s <literal>--disable-rpath</> + option. Also, you will need to tell the operating system how + to find the shared libraries. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>--exec-prefix=<replaceable>EXEC-PREFIX</></option></term> + <listitem> + <para> + You can install architecture-dependent files under a + different prefix, <replaceable>EXEC-PREFIX</>, than what + <replaceable>PREFIX</> was set to. This can be useful to + share architecture-independent files between hosts. If you + omit this, then <replaceable>EXEC-PREFIX</> is set equal to + <replaceable>PREFIX</> and both architecture-dependent and + independent files will be installed under the same tree, + which is probably what you want. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>--bindir=<replaceable>DIRECTORY</></option></term> + <listitem> + <para> + Specifies the directory for executable programs. The default + is <filename><replaceable>EXEC-PREFIX</>/bin</>, which + normally means <filename>/usr/local/pgsql/bin</>. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>--datadir=<replaceable>DIRECTORY</></option></term> + <listitem> + <para> + Sets the directory for read-only data files used by the + installed programs. The default is + <filename><replaceable>PREFIX</>/share</>. Note that this has + nothing to do with where your database files will be placed. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>--sysconfdir=<replaceable>DIRECTORY</></option></term> + <listitem> + <para> + The directory for various configuration files, + <filename><replaceable>PREFIX</>/etc</> by default. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>--libdir=<replaceable>DIRECTORY</></option></term> + <listitem> + <para> + The location to install libraries and dynamically loadable + modules. The default is + <filename><replaceable>EXEC-PREFIX</>/lib</>. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>--includedir=<replaceable>DIRECTORY</></option></term> + <listitem> + <para> + The directory for installing C and C++ header files. The + default is <filename><replaceable>PREFIX</>/include</>. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>--mandir=<replaceable>DIRECTORY</></option></term> + <listitem> + <para> + The man pages that come with <productname>PostgreSQL</> will be installed under + this directory, in their respective + <filename>man<replaceable>x</></> subdirectories. + The default is <filename><replaceable>PREFIX</>/man</>. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>--with-docdir=<replaceable>DIRECTORY</></option></term> + <term><option>--without-docdir</option></term> + <listitem> + <para> + Documentation files, except <quote>man</> pages, will be + installed into this directory. The default is + <filename><replaceable>PREFIX</>/doc</>. If the option + <option>--without-docdir</option> is specified, the + documentation will not be installed by <command>make + install</command>. This is intended for packaging scripts + that have special methods for installing documentation. + </para> + </listitem> + </varlistentry> + </variablelist> + + <note> + <para> + Care has been taken to make it possible to install + <productname>PostgreSQL</> into shared installation locations + (such as <filename>/usr/local/include</filename>) without + interfering with the namespace of the rest of the system. First, + the string <quote><literal>/postgresql</literal></quote> is + automatically appended to <varname>datadir</varname>, + <varname>sysconfdir</varname>, and <varname>docdir</varname>, + unless the fully expanded directory name already contains the + string <quote><literal>postgres</></quote> or + <quote><literal>pgsql</></quote>. For example, if you choose + <filename>/usr/local</filename> as prefix, the documentation will + be installed in <filename>/usr/local/doc/postgresql</filename>, + but if the prefix is <filename>/opt/postgres</filename>, then it + will be in <filename>/opt/postgres/doc</filename>. The public C + header files of the client interfaces are installed into + <varname>includedir</varname> and are namespace-clean. The + internal header files and the server header files are installed + into private directories under <varname>includedir</varname>. 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 <varname>libdir</varname> + for dynamically loadable modules. + </para> + </note> + </para> + + <para> + <variablelist> + <varlistentry> + <term><option>--with-includes=<replaceable>DIRECTORIES</></option></term> + <listitem> + <para> + <replaceable>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 <application>Readline</>) installed in a non-standard + location, + you have to use this option and probably also the corresponding + <option>--with-libraries</> option. + </para> + <para> + Example: <literal>--with-includes=/opt/gnu/include:/usr/sup/include</>. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>--with-libraries=<replaceable>DIRECTORIES</></option></term> + <listitem> + <para> + <replaceable>DIRECTORIES</> is a colon-separated list of + directories to search for libraries. You will probably have + to use this option (and the corresponding + <option>--with-includes</> option) if you have packages + installed in non-standard locations. + </para> + <para> + Example: <literal>--with-libraries=/opt/gnu/lib:/usr/sup/lib</>. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>--enable-nls<optional>=<replaceable>LANGUAGES</replaceable></optional></option></term> + <listitem> + <para> + Enables Native Language Support (<acronym>NLS</acronym>), + that is, the ability to display a program's messages in a + language other than English. + <replaceable>LANGUAGES</replaceable> is a space separated + list of codes of the languages that you want supported, for + example <literal>--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. + </para> + + <para> + To use this option, you will need an implementation of the + <application>Gettext</> API; see above. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>--with-pgport=<replaceable>NUMBER</></option></term> + <listitem> + <para> + Set <replaceable>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 + <productname>PostgreSQL</> servers on the same machine. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>--with-perl</option></term> + <listitem> + <para> + Build the <application>PL/Perl</> server-side language. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>--with-python</option></term> + <listitem> + <para> + Build the <application>PL/Python</> server-side language. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>--with-tcl</option></term> + <listitem> + <para> + Build the <application>PL/Tcl</> server-side language. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>--with-tclconfig=<replaceable>DIRECTORY</replaceable></option></term> + <listitem> + <para> + Tcl installs the file <filename>tclConfig.sh</filename>, 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 it. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>--with-krb4</option></term> + <term><option>--with-krb5</option></term> + <listitem> + <para> + Build with support for Kerberos authentication. You can use + either Kerberos version 4 or 5, but not both. On many + systems, the Kerberos system is not installed in a location + that is searched by default (e.g., <filename>/usr/include</>, + <filename>/usr/lib</>), so you must use the options + <option>--with-includes</> and <option>--with-libraries</> in + addition to this option. <filename>configure</> will check + for the required header files and libraries to make sure that + your Kerberos installation is sufficient before proceeding. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>--with-krb-srvnam=<replaceable>NAME</></option></term> + <listitem> + <para> + The name of the Kerberos service principal. + <literal>postgres</literal> is the default. There's probably no + reason to change this. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <indexterm> + <primary>OpenSSL</primary> + <seealso>SSL</seealso> + </indexterm> + + <term><option>--with-openssl</option></term> + <listitem> + <para> + Build with support for <acronym>SSL</> (encrypted) + connections. This requires the <productname>OpenSSL</> + package to be installed. <filename>configure</> will check + for the required header files and libraries to make sure that + your <productname>OpenSSL</> installation is sufficient + before proceeding. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>--with-pam</option></term> + <listitem> + <para> + Build with <acronym>PAM</><indexterm><primary>PAM</></> + (Pluggable Authentication Modules) support. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>--without-readline</option></term> + <listitem> + <para> + Prevents the use of the <application>Readline</> library. This disables + command-line editing and history in + <application>psql</application>, so it is not recommended. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>--with-rendezvous</option></term> + <listitem> + <para> + Build with Rendezvous support. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>--disable-spinlocks</option></term> + <listitem> + <para> + Allow the build to succeed even if <productname>PostgreSQL</> + has no CPU spinlock support for the platform. The lack of + spinlock support will result in 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 <productname>PostgreSQL</> on + your platform, please report the problem to the + <productname>PostgreSQL</> developers. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>--enable-thread-safety</option></term> + <listitem> + <para> + Make the client libraries thread-safe. This allows + concurrent threads in <application>libpq</application> and + <application>ECPG</application> programs to safely control + their private connection handles. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>--without-zlib</option></term> + <listitem> + <para> + Prevents the use of the <application>Zlib</> library. This disables + compression support in <application>pg_dump</application>. + This option is only intended for those rare systems where this + library is not available. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>--enable-debug</option></term> + <listitem> + <para> + 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. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>--enable-cassert</option></term> + <listitem> + <para> + Enables <firstterm>assertion</> checks in the server, which test for + many <quote>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. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>--enable-depend</option></term> + <listitem> + <para> + 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. + </para> + </listitem> + </varlistentry> + + </variablelist> + </para> + + <para> + If you prefer a C compiler different from the one + <filename>configure</filename> picks then you can set the + environment variable <envar>CC</> to the program of your choice. + By default, <filename>configure</filename> will pick + <filename>gcc</filename> unless this is inappropriate for the + platform. Similarly, you can override the default compiler flags + with the <envar>CFLAGS</envar> variable. + </para> + + <para> + You can specify environment variables on the + <filename>configure</filename> command line, for example: +<screen> +<userinput>./configure CC=/opt/bin/gcc CFLAGS='-O2 -pipe'</> +</screen> + </para> + </step> + + <step> + <title>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. + + + + + + Regression Tests + + + regression test + + + + 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.) + src/test/regress/README and the + documentation contain]]> + contains]]> + detailed information about interpreting the test results. You can + repeat this test at any later time by issuing the same command. + + + + + Installing The Files + + + + 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 + above. + + + + + To install PostgreSQL enter + +gmake install + + This will install files into the directories that were specified + in . 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 all the header files needed for client + application development as well as for any 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: + +gmake -C src/bin install +gmake -C src/include install +gmake -C src/interfaces install +gmake -C doc install + + + + + + + + Registering <application>eventlog</> on <systemitem + class="osname">Windows</>: + + To register a Windows eventlog + library with the operating system, issue this command after installation: + +regsvr32 pgsql_library_directory/pgevent.dll + + This creates registry entries used by the event viewer. + + + + + 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 + + + shared library + + + + 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 + + + + 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. + + + + + ldconfig + + 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 + + + PATH + + + + 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 + + + + 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 ) + + + + + + MANPATH + + 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. + + + + + + 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 + + + + + + + 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 + + + + + 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 \ + </dev/null >>server.log 2>&1 </dev/null & + + + + + To stop a server running in the background you can type + +kill `cat /usr/local/pgsql/data/postmaster.pid` + + + + + In order to allow TCP/IP connections (rather than only Unix + domain socket ones) you need to pass the + + + + + Create a database: + +createdb testdb + + Then enter + +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 + gmake 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 + + + PostgreSQL has been verified by the developer + community to work on the platforms listed below. A supported + platform generally means that PostgreSQL builds and + installs according to these instructions and that the regression + tests pass. Build farm entries refer to builds + reported by the PostgreSQL + Build Farm. + + + + + If you are having problems with the installation on a supported + platform, please write to pgsql-bugs@postgresql.org + or pgsql-ports@postgresql.org, not to the people + listed here. + + + + + + + + OS + Processor + Version + Reported + Remarks + + + + + AIX + PowerPC + 8.0.0 + Travis P (twp@castle.fastmail.fm), 2004-12-12 + see also doc/FAQ_AIX + + + AIX + RS6000 + 8.0.0 + Hans-Jürgen Schönig (hs@cybertec.at), 2004-12-06 + see also doc/FAQ_AIX + + + BSD/OS + x86 + 8.0.0 + Bruce Momjian (pgman@candle.pha.pa.us), 2004-12-07 + 4.3.1 + + + Debian GNU/Linux + Alpha + 7.4 + Noèl Köthe (noel@debian.org), 2003-10-25 + + + + Debian GNU/Linux + AMD64 + 8.0.0 + Build farm panda, snapshot 2004-12-06 01:20:02 + sid, kernel 2.6 + + + Debian GNU/Linux + arm41 + 7.4 + Noèl Köthe (noel@debian.org), 2003-10-25 + + + + Debian GNU/Linux + Itanium + 7.4 + Noèl Köthe (noel@debian.org), 2003-10-25 + + + + Debian GNU/Linux + m68k + 8.0.0 + Noèl Köthe (noel@debian.org), 2004-12-09 + sid + + + Debian GNU/Linux + MIPS + 8.0.0 + Build farm lionfish, snapshot 2004-12-06 11:00:08 + 3.1 (sarge), kernel 2.4 + + + Debian GNU/Linux + PA-RISC + 8.0.0 + Noèl Köthe (noel@debian.org), 2004-12-07 + + + + Debian GNU/Linux + PowerPC + 8.0.0 + Noèl Köthe (noel@debian.org), 2004-12-15 + + + + Debian GNU/Linux + S/390 + 7.4 + Noèl Köthe (noel@debian.org), 2003-10-25 + + + + Debian GNU/Linux + Sparc + 8.0.0 + Noèl Köthe (noel@debian.org), 2004-12-09 + sid, 32-bit + + + Debian GNU/Linux + x86 + 8.0.0 + Peter Eisentraut (peter_e@gmx.net), 2004-12-06 + 3.1 (sarge), kernel 2.6 + + + Fedora + AMD64 + 8.0.0 + John Gray (jgray@azuli.co.uk), 2004-12-12 + FC3 + + + Fedora + x86 + 8.0.0 + Build farm dog, snapshot 2004-12-06 02:06:01 + FC1 + + + FreeBSD + Alpha + 7.4 + Peter Eisentraut (peter_e@gmx.net), 2003-10-25 + 4.8 + + + FreeBSD + x86 + 8.0.0 + Build farm cockatoo, snapshot 2004-12-06 14:10:01 (4.10); + Marc Fournier (scrappy@postgresql.org), 2004-12-07 (5.3) + + + + Gentoo Linux + x86 + 8.0.0 + Paul Bort (pbort@tmwsystems.com), 2004-12-07 + + + + HP-UX + PA-RISC + 7.4 + + Tom Lane (tgl@sss.pgh.pa.us), 2003-10-31 (10.20); + Peter Eisentraut (peter_e@gmx.net), 2003-11-04 (11.00) + + gcc and cc; see also doc/FAQ_HPUX + + + IRIX + MIPS + 7.4 + Robert E. Bruccoleri (bruc@stone.congenomics.com), 2003-11-12 + 6.5.20, cc only + + + Mac OS X + PowerPC + 8.0.0 + Andrew Rawnsley (ronz@ravensfield.com), 2004-12-07 + 10.3.5 + + + Mandrakelinux + x86 + 8.0.0 + Build farm shrew, snapshot 2004-12-06 02:02:01 + 10.0 + + + NetBSD + arm32 + 7.4 + Patrick Welche (prlw1@newn.cam.ac.uk), 2003-11-12 + 1.6ZE/acorn32 + + + NetBSD + Sparc + 7.4.1 + Peter Eisentraut (peter_e@gmx.net), 2003-11-26 + 1.6.1, 32-bit + + + NetBSD + x86 + 8.0.0 + Build farm canary, snapshot 2004-12-06 03:30:00 + 1.6 + + + OpenBSD + Sparc + 7.4 + Peter Eisentraut (peter_e@gmx.net), 2003-11-01 + 3.4 + + + OpenBSD + x86 + 8.0.0 + Build farm emu, snapshot 2004-12-06 11:35:03 + 3.6 + + + Red Hat Linux + AMD64 + 8.0.0 + Tom Lane (tgl@sss.pgh.pa.us), 2004-12-07 + RHEL 3AS + + + Red Hat Linux + IA64 + 8.0.0 + Tom Lane (tgl@sss.pgh.pa.us), 2004-12-07 + RHEL 3AS + + + Red Hat Linux + PowerPC + 8.0.0 + Tom Lane (tgl@sss.pgh.pa.us), 2004-12-07 + RHEL 3AS + + + Red Hat Linux + PowerPC 64 + 8.0.0 + Tom Lane (tgl@sss.pgh.pa.us), 2004-12-07 + RHEL 3AS + + + Red Hat Linux + S/390 + 8.0.0 + Tom Lane (tgl@sss.pgh.pa.us), 2004-12-07 + RHEL 3AS + + + Red Hat Linux + S/390x + 8.0.0 + Tom Lane (tgl@sss.pgh.pa.us), 2004-12-07 + RHEL 3AS + + + Red Hat Linux + x86 + 8.0.0 + Tom Lane (tgl@sss.pgh.pa.us), 2004-12-07 + RHEL 3AS + + + Solaris + Sparc + 8.0.0 + Kenneth Marshall (ktm@is.rice.edu), 2004-12-07 + Solaris 8; see also doc/FAQ_Solaris + + + Solaris + x86 + 8.0.0 + Build farm kudu, snapshot 2004-12-10 02:30:04 (cc); + dragonfly, snapshot 2004-12-09 04:30:00 (gcc) + Solaris 9; see also doc/FAQ_Solaris + + + Tru64 UNIX + Alpha + 7.4 + Peter Eisentraut (peter_e@gmx.net), 2003-10-25 (5.1b); + Alessio Bragadini (alessio@albourne.com), 2003-10-29 (4.0g) + + + + UnixWare + x86 + 8.0.0 + Peter Eisentraut (peter_e@gmx.net), 2004-12-14 + cc, 7.1.4; see also doc/FAQ_SCO + + + Windows + x86 + 8.0.0 + Dave Page (dpage@vale-housing.co.uk), 2004-12-07 + see doc/FAQ_MINGW + + + Windows with Cygwin + x86 + 8.0.0 + Build farm gibbon, snapshot 2004-12-11 01:33:01 + see doc/FAQ_CYGWIN + + + + + + + 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 &majorversion; 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 (cyril.velter@libertysurf.fr) + needs updates to semaphore code + + + Linux + PlayStation 2 + 7.4 + 2003-11-02, + Peter Eisentraut (peter_e@gmx.net) + + needs new config.guess, + + + + + NetBSD + Alpha + 7.2 + 2001-11-20, + Thomas Thai (tom@minnesota.com) + 1.5W + + + NetBSD + MIPS + 7.2.1 + 2002-06-13, + Warwick Hunter (whunter@agile.tv) + 1.5.3 + + + NetBSD + PowerPC + 7.2 + 2001-11-28, + Bill Studenmund (wrstuden@netbsd.org) + 1.5 + + + NetBSD + VAX + 7.1 + 2001-03-30, + Tom I. Helbekkmo (tih@kpnQwest.no) + 1.5 + + + QNX 4 RTOS + x86 + 7.2 + 2001-12-10, + Bernd Tegge (tegge@repas-aeg.de) + + needs updates to semaphore code; + see also doc/FAQ_QNX4 + + + QNX RTOS v6 + x86 + 7.2 + 2001-11-20, Igor Kovalenko (Igor.Kovalenko@motorola.com) + patches available in archives, but too late for 7.2 + + + SCO OpenServer + x86 + 7.3.1 + 2002-12-11, + Shibashish Satpathy (shib@postmark.net) + 5.0.4, gcc; see also doc/FAQ_SCO + + + SunOS 4 + Sparc + 7.2 + 2001-12-04, Tatsuo Ishii (t-ishii@sra.co.jp) + + + + + + + + + +