2020 lines
72 KiB
Plaintext
2020 lines
72 KiB
Plaintext
<!-- $PostgreSQL: pgsql/doc/src/sgml/installation.sgml,v 1.313 2008/09/05 12:11:18 petere Exp $ -->
|
|
|
|
<chapter id="installation">
|
|
<title><![%standalone-include[<productname>PostgreSQL</>]]>
|
|
Installation Instructions</title>
|
|
|
|
<indexterm zone="installation">
|
|
<primary>installation</primary>
|
|
</indexterm>
|
|
|
|
<para>
|
|
This <![%standalone-include;[document]]>
|
|
<![%standalone-ignore;[chapter]]> describes the installation of
|
|
<productname>PostgreSQL</productname> from the source code
|
|
distribution. (If you are installing a pre-packaged distribution,
|
|
such as an RPM or Debian package, ignore this
|
|
<![%standalone-include;[document]]>
|
|
<![%standalone-ignore;[chapter]]>
|
|
and read the packager's instructions instead.)
|
|
</para>
|
|
|
|
<sect1 id="install-short">
|
|
<title>Short Version</title>
|
|
|
|
<para>
|
|
<synopsis>
|
|
./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/postgres -D /usr/local/pgsql/data >logfile 2>&1 &
|
|
/usr/local/pgsql/bin/createdb test
|
|
/usr/local/pgsql/bin/psql test
|
|
</synopsis>
|
|
The long version is the rest of this
|
|
<![%standalone-include;[document.]]>
|
|
<![%standalone-ignore;[chapter.]]>
|
|
</para>
|
|
</sect1>
|
|
|
|
|
|
<sect1 id="install-requirements">
|
|
<title>Requirements</title>
|
|
|
|
<para>
|
|
In general, a modern Unix-compatible platform should be able to run
|
|
<productname>PostgreSQL</>.
|
|
The platforms that had received specific testing at the
|
|
time of release are listed in <xref linkend="supported-platforms">
|
|
below. In the <filename>doc</> subdirectory of the distribution
|
|
there are several platform-specific <acronym>FAQ</> documents you
|
|
might wish to consult if you are having trouble.
|
|
</para>
|
|
|
|
<para>
|
|
The following software packages are required for building
|
|
<productname>PostgreSQL</>:
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>
|
|
<indexterm>
|
|
<primary>make</primary>
|
|
</indexterm>
|
|
|
|
<acronym>GNU</> <application>make</> is required; other
|
|
<application>make</> programs will <emphasis>not</> work.
|
|
<acronym>GNU</> <application>make</> is often installed under
|
|
the name <filename>gmake</filename>; this document will always
|
|
refer to it by that name. (On some systems
|
|
<acronym>GNU</acronym> <application>make</> is the default tool with the name
|
|
<filename>make</>.) To test for <acronym>GNU</acronym>
|
|
<application>make</application> enter
|
|
<screen>
|
|
<userinput>gmake --version</userinput>
|
|
</screen>
|
|
It is recommended to use version 3.76.1 or later.
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
You need an <acronym>ISO</>/<acronym>ANSI</> C compiler. Recent
|
|
versions of <productname>GCC</> are recommendable, but
|
|
<productname>PostgreSQL</> is known to build with a wide variety
|
|
of compilers from different vendors.
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
<application>tar</> is required to unpack the source
|
|
distribution in the first place, in addition to either
|
|
<application>gzip</> or <application>bzip2</>.
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
<indexterm>
|
|
<primary>readline</primary>
|
|
</indexterm>
|
|
<indexterm>
|
|
<primary>libedit</primary>
|
|
</indexterm>
|
|
|
|
The <acronym>GNU</> <productname>Readline</> library (for
|
|
simple line editing and command history retrieval) is
|
|
used by default. If you don't want to use it then you must specify
|
|
the <option>--without-readline</option> option for
|
|
<filename>configure</>. As an alternative, you can often use the
|
|
BSD-licensed <filename>libedit</filename> library, originally
|
|
developed on <productname>NetBSD</productname>. The
|
|
<filename>libedit</filename> library is
|
|
GNU <productname>Readline</productname>-compatible and is used if
|
|
<filename>libreadline</filename> is not found, or if
|
|
<option>--with-libedit-preferred</option> is used as an
|
|
option to <filename>configure</>. If you are using a package-based
|
|
Linux distribution, be aware that you need both the
|
|
<literal>readline</> and <literal>readline-devel</> packages, if
|
|
those are separate in your distribution.
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
<indexterm>
|
|
<primary>zlib</primary>
|
|
</indexterm>
|
|
|
|
The <productname>zlib</productname> compression library will be
|
|
used by default. If you don't want to use it then you must
|
|
specify the <option>--without-zlib</option> option for
|
|
<filename>configure</filename>. Using this option disables
|
|
support for compressed archives in <application>pg_dump</> and
|
|
<application>pg_restore</>.
|
|
</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</para>
|
|
|
|
<para>
|
|
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.
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>
|
|
To build the server programming language
|
|
<application>PL/Perl</application> you need a full
|
|
<productname>Perl</productname> installation, including the
|
|
<filename>libperl</filename> library and the header files.
|
|
Since <application>PL/Perl</application> will be a shared
|
|
library, the <indexterm><primary>libperl</primary></indexterm>
|
|
<filename>libperl</filename> library must be a shared library
|
|
also on most platforms. This appears to be the default in
|
|
recent <productname>Perl</productname> versions, but it was not
|
|
in earlier versions, and in any case it is the choice of whomever
|
|
installed Perl at your site.
|
|
</para>
|
|
|
|
<para>
|
|
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:
|
|
<screen>
|
|
*** 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.
|
|
</screen>
|
|
(If you don't follow the on-screen output you will merely notice
|
|
that the <application>PL/Perl</application> library object,
|
|
<filename>plperl.so</filename> or similar, will not be
|
|
installed.) If you see this, you will have to rebuild and
|
|
install <productname>Perl</productname> manually to be able to
|
|
build <application>PL/Perl</application>. During the
|
|
configuration process for <productname>Perl</productname>,
|
|
request a shared library.
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
To build the <application>PL/Python</> server programming
|
|
language, you need a <productname>Python</productname>
|
|
installation with the header files and the <application>distutils</application> module.
|
|
The <application>distutils</application> module is included by default with
|
|
<productname>Python</productname> 1.6 and later; users of
|
|
earlier versions of <productname>Python</productname> will need
|
|
to install it.
|
|
</para>
|
|
|
|
<para>
|
|
Since <application>PL/Python</application> will be a shared
|
|
library, the <indexterm><primary>libpython</primary></indexterm>
|
|
<filename>libpython</filename> library must be a shared library
|
|
also on most platforms. This is not the case in a default
|
|
<productname>Python</productname> installation. If after
|
|
building and installing you have a file called
|
|
<filename>plpython.so</filename> (possibly a different
|
|
extension), then everything went well. Otherwise you should
|
|
have seen a notice like this flying by:
|
|
<screen>
|
|
*** 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.
|
|
</screen>
|
|
That means you have to rebuild (part of) your
|
|
<productname>Python</productname> installation to supply this
|
|
shared library.
|
|
</para>
|
|
|
|
<para>
|
|
If you have problems, run <productname>Python</> 2.3 or later's
|
|
configure using the <literal>--enable-shared</> flag. On some
|
|
operating systems you don't have to build a shared library, but
|
|
you will have to convince the <productname>PostgreSQL</> build
|
|
system of this. Consult the <filename>Makefile</filename> in
|
|
the <filename>src/pl/plpython</filename> directory for details.
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
If you want to build the <application>PL/Tcl</application>
|
|
procedural language, you of course need a <productname>Tcl</>
|
|
installation. If you are using a pre-8.4 release of
|
|
<productname>Tcl</>, ensure that it was built without multithreading
|
|
support.
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
To enable Native Language Support (<acronym>NLS</acronym>), that
|
|
is, the ability to display a program's messages in a language
|
|
other than English, you need an implementation of the
|
|
<application>Gettext</> <acronym>API</acronym>. Some operating
|
|
systems have this built-in (e.g., <systemitem
|
|
class="osname">Linux</>, <systemitem class="osname">NetBSD</>,
|
|
<systemitem class="osname">Solaris</>), for other systems you
|
|
can download an add-on package from <ulink
|
|
url="http://developer.postgresql.org/~petere/bsd-gettext/"></ulink>.
|
|
If you are using the <application>Gettext</> implementation in
|
|
the <acronym>GNU</acronym> C library then you will additionally
|
|
need the <productname>GNU Gettext</productname> package for some
|
|
utility programs. For any of the other implementations you will
|
|
not need it.
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
<application>Kerberos</>, <productname>OpenSSL</>,
|
|
<productname>OpenLDAP</>, and/or
|
|
<application>PAM</>, if you want to support authentication or
|
|
encryption using these services.
|
|
</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</para>
|
|
|
|
<para>
|
|
If you are building from a <acronym>CVS</acronym> tree instead of
|
|
using a released source package, or if you want to do development,
|
|
you also need the following packages:
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>
|
|
<indexterm>
|
|
<primary>flex</primary>
|
|
</indexterm>
|
|
<indexterm>
|
|
<primary>lex</primary>
|
|
</indexterm>
|
|
<indexterm>
|
|
<primary>bison</primary>
|
|
</indexterm>
|
|
<indexterm>
|
|
<primary>yacc</primary>
|
|
</indexterm>
|
|
|
|
GNU <application>Flex</> and <application>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 <application>Flex</> 2.5.4 or later and
|
|
<application>Bison</> 1.875 or later. Other <application>lex</>
|
|
and <application>yacc</> programs cannot be used.
|
|
</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</para>
|
|
|
|
<para>
|
|
If you need to get a <acronym>GNU</acronym> package, you can find
|
|
it at your local <acronym>GNU</acronym> mirror site (see <ulink
|
|
url="http://www.gnu.org/order/ftp.html"></>
|
|
for a list) or at <ulink
|
|
url="ftp://ftp.gnu.org/gnu/"></ulink>.
|
|
</para>
|
|
|
|
<para>
|
|
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 <command>df</command> command to check free disk
|
|
space.
|
|
</para>
|
|
</sect1>
|
|
|
|
<![%standalone-ignore;[
|
|
<sect1 id="install-getsource">
|
|
<title>Getting The Source</title>
|
|
|
|
<para>
|
|
The <productname>PostgreSQL</> &version; sources can be obtained by
|
|
anonymous FTP from <ulink
|
|
url="ftp://ftp.postgresql.org/pub/source/v&version;/postgresql-&version;.tar.gz"></ulink>.
|
|
Other download options can be found on our website:
|
|
<ulink url="http://www.postgresql.org/download/"></ulink>. After you
|
|
have obtained the file, unpack it:
|
|
<screen>
|
|
<userinput>gunzip postgresql-&version;.tar.gz</userinput>
|
|
<userinput>tar xf postgresql-&version;.tar</userinput>
|
|
</screen>
|
|
This will create a directory
|
|
<filename>postgresql-&version;</filename> under the current directory
|
|
with the <productname>PostgreSQL</> sources.
|
|
Change into that directory for the rest
|
|
of the installation procedure.
|
|
</para>
|
|
</sect1>
|
|
]]>
|
|
|
|
<sect1 id="install-upgrading">
|
|
<title>Upgrading</title>
|
|
|
|
<indexterm zone="install-upgrading">
|
|
<primary>upgrading</primary>
|
|
</indexterm>
|
|
|
|
<para>
|
|
These instructions assume that your existing installation is under the
|
|
<filename>/usr/local/pgsql</> directory, and that the data area is in
|
|
<filename>/usr/local/pgsql/data</>. Substitute your paths
|
|
appropriately.
|
|
</para>
|
|
|
|
<para>
|
|
The internal data storage format typically changes in every major
|
|
release of <productname>PostgreSQL</>. Therefore, if you are upgrading
|
|
an existing installation that does not have a version number of
|
|
<quote>&majorversion;.x</quote>, you must back up and restore your
|
|
data. If you are upgrading from <productname>PostgreSQL</>
|
|
<quote>&majorversion;.x</quote>, the new version can use your current
|
|
data files so you should skip the backup and restore steps below because
|
|
they are unnecessary.
|
|
</para>
|
|
|
|
<procedure>
|
|
<step>
|
|
<para>
|
|
If making a backup, make sure that your database is not being updated.
|
|
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 <filename>/usr/local/pgsql/data/pg_hba.conf</>
|
|
(or equivalent) to disallow access from everyone except you.
|
|
</para>
|
|
|
|
<para>
|
|
<indexterm>
|
|
<primary>pg_dumpall</primary>
|
|
<secondary>use during upgrade</secondary>
|
|
</indexterm>
|
|
|
|
To back up your database installation, type:
|
|
<screen>
|
|
<userinput>pg_dumpall > <replaceable>outputfile</></userinput>
|
|
</screen>
|
|
If you need to preserve OIDs (such as when using them as
|
|
foreign keys), then use the <option>-o</option> option when running
|
|
<application>pg_dumpall</>.
|
|
</para>
|
|
|
|
<para>
|
|
To make the backup, you can use the <application>pg_dumpall</application>
|
|
command from the version you are currently running. For best
|
|
results, however, try to use the <application>pg_dumpall</application>
|
|
command from <productname>PostgreSQL</productname> &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.
|
|
</para>
|
|
</step>
|
|
|
|
<step>
|
|
<para>
|
|
Shut down the old server:
|
|
<screen>
|
|
<userinput>pg_ctl stop</>
|
|
</screen>
|
|
On systems that have <productname>PostgreSQL</> started at boot time,
|
|
there is probably a start-up file that will accomplish the same thing. For
|
|
example, on a <systemitem class="osname">Red Hat Linux</> system one
|
|
might find that
|
|
<screen>
|
|
<userinput>/etc/rc.d/init.d/postgresql stop</userinput>
|
|
</screen>
|
|
works.
|
|
</para>
|
|
</step>
|
|
|
|
<step>
|
|
<para>
|
|
If restoring from backup, rename or delete the old installation
|
|
directory. It is a good idea to rename the directory, rather than
|
|
delete it, in case you have trouble and need to revert to it. Keep
|
|
in mind the directory might consume significant disk space. To rename
|
|
the directory, use a command like this:
|
|
<screen>
|
|
<userinput>mv /usr/local/pgsql /usr/local/pgsql.old</>
|
|
</screen>
|
|
</para>
|
|
</step>
|
|
|
|
<step>
|
|
<para>
|
|
Install the new version of <productname>PostgreSQL</productname> as
|
|
outlined in <![%standalone-include[the next section.]]>
|
|
<![%standalone-ignore[<xref linkend="install-procedure">.]]>
|
|
</para>
|
|
</step>
|
|
|
|
<step>
|
|
<para>
|
|
Create a new database cluster if needed. Remember that you must
|
|
execute these commands while logged in to the special database user
|
|
account (which you already have if you are upgrading).
|
|
<programlisting>
|
|
<userinput>/usr/local/pgsql/bin/initdb -D /usr/local/pgsql/data</>
|
|
</programlisting>
|
|
</para>
|
|
</step>
|
|
|
|
<step>
|
|
<para>
|
|
Restore your previous <filename>pg_hba.conf</> and any
|
|
<filename>postgresql.conf</> modifications.
|
|
</para>
|
|
</step>
|
|
|
|
<step>
|
|
<para>
|
|
Start the database server, again from the special database user
|
|
account:
|
|
<programlisting>
|
|
<userinput>/usr/local/pgsql/bin/postgres -D /usr/local/pgsql/data</>
|
|
</programlisting>
|
|
</para>
|
|
</step>
|
|
|
|
<step>
|
|
<para>
|
|
Finally, restore your data from backup with
|
|
<screen>
|
|
<userinput>/usr/local/pgsql/bin/psql -d postgres -f <replaceable>outputfile</></userinput>
|
|
</screen>
|
|
using the <emphasis>new</> <application>psql</>.
|
|
</para>
|
|
</step>
|
|
</procedure>
|
|
|
|
<para>
|
|
Further discussion appears in
|
|
<![%standalone-include[the documentation,]]>
|
|
<![%standalone-ignore[<xref linkend="migration">,]]>
|
|
including instructions on how the previous installation can continue
|
|
running while the new installation is installed.
|
|
</para>
|
|
</sect1>
|
|
|
|
|
|
<sect1 id="install-procedure">
|
|
<title>Installation Procedure</title>
|
|
|
|
<procedure>
|
|
|
|
<step id="configure">
|
|
<title>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>--sysconfdir=<replaceable>DIRECTORY</></option></term>
|
|
<listitem>
|
|
<para>
|
|
Sets 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>
|
|
Sets 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>
|
|
Sets the directory for installing C and C++ header files. The
|
|
default is <filename><replaceable>PREFIX</>/include</>.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>--datarootdir=<replaceable>DIRECTORY</></option></term>
|
|
<listitem>
|
|
<para>
|
|
Sets the root directory for various types of read-only data
|
|
files. This only sets the default for some of the following
|
|
options. The default is
|
|
<filename><replaceable>PREFIX</>/share</>.
|
|
</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>DATAROOTDIR</></>. Note that this has
|
|
nothing to do with where your database files will be placed.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>--localedir=<replaceable>DIRECTORY</></option></term>
|
|
<listitem>
|
|
<para>
|
|
Sets the directory for installing locale data, in particular
|
|
message translation catalog files. The default is
|
|
<filename><replaceable>DATAROOTDIR</>/locale</>.
|
|
</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>DATAROOTDIR</>/man</>.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>--docdir=<replaceable>DIRECTORY</></option></term>
|
|
<listitem>
|
|
<para>
|
|
Sets the root directory for installing documentation files,
|
|
except <quote>man</> pages. This only sets the default for
|
|
the following options. The default value for this option is
|
|
<filename><replaceable>DATAROOTDIR</>/doc/postgresql</>.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>--htmldir=<replaceable>DIRECTORY</></option></term>
|
|
<listitem>
|
|
<para>
|
|
The HTML-formatted documentation for
|
|
<productname>PostgreSQL</productname> will be installed under
|
|
this directory. The default is
|
|
<filename><replaceable>DATAROOTDIR</></>.
|
|
</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-gssapi</option></term>
|
|
<listitem>
|
|
<para>
|
|
Build with support for GSSAPI authentication. On many
|
|
systems, the GSSAPI (usually a part of the Kerberos installation)
|
|
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 GSSAPI installation is sufficient before proceeding.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>--with-krb5</option></term>
|
|
<listitem>
|
|
<para>
|
|
Build with support for Kerberos 5 authentication. 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 default name of the Kerberos service principal (also used
|
|
by GSSAPI).
|
|
<literal>postgres</literal> is the default. There's usually no
|
|
reason to change this unless you have a Windows environment,
|
|
in which case it must be set to uppercase
|
|
<literal>POSTGRES</literal>.
|
|
</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>--with-ldap</option></term>
|
|
<listitem>
|
|
<para>
|
|
Build with <acronym>LDAP</><indexterm><primary>LDAP</></>
|
|
support for authentication and connection parameter lookup (see
|
|
<![%standalone-include[the documentation about client authentication
|
|
and libpq]]><![%standalone-ignore[<xref linkend="libpq-ldap"> and
|
|
<xref linkend="auth-ldap">]]> for more information). On Unix,
|
|
this requires the <productname>OpenLDAP</> package to be
|
|
installed. <filename>configure</> will check for the required
|
|
header files and libraries to make sure that your
|
|
<productname>OpenLDAP</> installation is sufficient before
|
|
proceeding. On Windows, the default <productname>WinLDAP</>
|
|
library is used.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>--without-readline</option></term>
|
|
<listitem>
|
|
<para>
|
|
Prevents use of the <application>Readline</> library
|
|
(and <application>libedit</> as well). This option disables
|
|
command-line editing and history in
|
|
<application>psql</application>, so it is not recommended.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>--with-libedit-preferred</option></term>
|
|
<listitem>
|
|
<para>
|
|
Favors the use of the BSD-licensed <application>libedit</> library
|
|
rather than GPL-licensed <application>Readline</>. This option
|
|
is significant only if you have both libraries installed; the
|
|
default in that case is to use <application>Readline</>.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>--with-bonjour</option></term>
|
|
<listitem>
|
|
<para>
|
|
Build with Bonjour support. This requires Bonjour support
|
|
in your operating system. Recommended on Mac OS X.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>--with-ossp-uuid</option></term>
|
|
<listitem>
|
|
<para>
|
|
Use the <ulink url="http://www.ossp.org/pkg/lib/uuid/">OSSP UUID
|
|
library</ulink> when building <filename>contrib/uuid-ossp</>.
|
|
The library provides functions to generate
|
|
UUIDs.<indexterm><primary>UUID</primary></indexterm>
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>--with-libxml</option></term>
|
|
<listitem>
|
|
<para>
|
|
Build with libxml (enables SQL/XML support). Libxml version 2.6.23 or
|
|
later is required for this feature.
|
|
</para>
|
|
|
|
<para>
|
|
Libxml installs a program <command>xml2-config</command> that
|
|
can be used to detect the required compiler and linker
|
|
options. PostgreSQL will use it automatically if found. To
|
|
specify a libxml installation at an unusual location, you can
|
|
either set the environment variable
|
|
<envar>XML2_CONFIG</envar> to point to the
|
|
<command>xml2-config</command> program belonging to the
|
|
installation, or use the options
|
|
<option>--with-includes</option> and
|
|
<option>--with-libraries</option>.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>--with-libxslt</option></term>
|
|
<listitem>
|
|
<para>
|
|
Use libxslt when building <filename>contrib/xml2</>.
|
|
<filename>contrib/xml2</> relies on this library to perform
|
|
XSL transformations of XML.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>--disable-integer-datetimes</option></term>
|
|
<listitem>
|
|
<para>
|
|
Disable support for 64-bit integer storage for timestamps and
|
|
intervals, and store datetime values as floating-point
|
|
numbers instead. Floating-point datetime storage was the
|
|
default in <productname>PostgreSQL</productname> releases
|
|
prior to 8.4, but it is now deprecated, because it does not
|
|
support microsecond precision for the full range of
|
|
<type>timestamp</type> values. However, integer-based
|
|
datetime storage requires a 64-bit integer type. Therefore,
|
|
this option can be used when no such type is available, or
|
|
for compatibility with applications written for prior
|
|
versions of <productname>PostgreSQL</productname>. See
|
|
<![%standalone-include[the documentation about datetime datatypes]]>
|
|
<![%standalone-ignore[<xref linkend="datatype-datetime">]]>
|
|
for more information.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>--disable-float4-byval</option></term>
|
|
<listitem>
|
|
<para>
|
|
Disable passing float4 values <quote>by value</>, causing them
|
|
to be passed <quote>by reference</> instead. This option costs
|
|
performance, but may be needed for compatibility with old
|
|
user-defined functions that are written in C and use the
|
|
<quote>version 0</> calling convention. A better long-term
|
|
solution is to update any such functions to use the
|
|
<quote>version 1</> calling convention.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>--disable-float8-byval</option></term>
|
|
<listitem>
|
|
<para>
|
|
Disable passing float8 values <quote>by value</>, causing them
|
|
to be passed <quote>by reference</> instead. This option costs
|
|
performance, but may be needed for compatibility with old
|
|
user-defined functions that are written in C and use the
|
|
<quote>version 0</> calling convention. A better long-term
|
|
solution is to update any such functions to use the
|
|
<quote>version 1</> calling convention.
|
|
Note that this option affects not only float8, but also int8 and some
|
|
related types such as timestamp.
|
|
On 32-bit platforms, <option>--disable-float8-byval</> is the default
|
|
and it is not allowed to select <option>--enable-float8-byval</>.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>--with-segsize=<replaceable>SEGSIZE</replaceable></option></term>
|
|
<listitem>
|
|
<para>
|
|
Set the <firstterm>segment size</>, in gigabytes. Large tables are
|
|
divided into multiple operating-system files, each of size equal
|
|
to the segment size. This avoids problems with file size limits
|
|
that exist on many platforms. The default segment size, 1 gigabyte,
|
|
is safe on all supported platforms. If your operating system has
|
|
<quote>largefile</> support (which most do, nowadays), you can use
|
|
a larger segment size. This can be helpful to reduce the number of
|
|
file descriptors consumed when working with very large tables.
|
|
But be careful not to select a value larger than is supported
|
|
by your platform and the filesystem(s) you intend to use. Other
|
|
tools you might wish to use, such as <application>tar</>, could
|
|
also set limits on the usable file size.
|
|
It is recommended, though not absolutely required, that this value
|
|
be a power of 2.
|
|
Note that changing this value requires an initdb.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>--with-blocksize=<replaceable>BLOCKSIZE</replaceable></option></term>
|
|
<listitem>
|
|
<para>
|
|
Set the <firstterm>block size</>, in kilobytes. This is the unit
|
|
of storage and I/O within tables. The default, 8 kilobytes,
|
|
is suitable for most situations; but other values may be useful
|
|
in special cases.
|
|
The value must be a power of 2 between 1 and 32 (kilobytes).
|
|
Note that changing this value requires an initdb.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>--with-wal-segsize=<replaceable>SEGSIZE</replaceable></option></term>
|
|
<listitem>
|
|
<para>
|
|
Set the <firstterm>WAL segment size</>, in megabytes. This is
|
|
the size of each individual file in the WAL log. It may be useful
|
|
to adjust this size to control the granularity of WAL log shipping.
|
|
The default size is 16 megabytes.
|
|
The value must be a power of 2 between 1 and 64 (megabytes).
|
|
Note that changing this value requires an initdb.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>--with-wal-blocksize=<replaceable>BLOCKSIZE</replaceable></option></term>
|
|
<listitem>
|
|
<para>
|
|
Set the <firstterm>WAL block size</>, in kilobytes. This is the unit
|
|
of storage and I/O within the WAL log. The default, 8 kilobytes,
|
|
is suitable for most situations; but other values may be useful
|
|
in special cases.
|
|
The value must be a power of 2 between 1 and 64 (kilobytes).
|
|
Note that changing this value requires an initdb.
|
|
</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. This option requires adequate
|
|
threading support in your operating system.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>--with-system-tzdata=<replaceable>DIRECTORY</replaceable></option></term>
|
|
<indexterm>
|
|
<primary>time zone data</primary>
|
|
</indexterm>
|
|
<listitem>
|
|
<para>
|
|
<productname>PostgreSQL</> includes its own time zone database,
|
|
which it requires for date and time operations. This time zone
|
|
database is in fact compatible with the <quote>zoneinfo</> time zone
|
|
database provided by many operating systems such as FreeBSD,
|
|
Linux, and Solaris, so it would be redundant to install it again.
|
|
When this option is used, the system-supplied time zone database
|
|
in <replaceable>DIRECTORY</replaceable> is used instead of the one
|
|
included in the PostgreSQL source distribution.
|
|
<replaceable>DIRECTORY</replaceable> must be specified as an
|
|
absolute path. <filename>/usr/share/zoneinfo</filename> is a
|
|
likely directory on some operating systems. Note that the
|
|
installation routine will not detect mismatching or erroneous time
|
|
zone data. If you use this option, you are advised to run the
|
|
regression tests to verify that the time zone data you have
|
|
pointed to works correctly with <productname>PostgreSQL</>.
|
|
</para>
|
|
|
|
<para>
|
|
This option is mainly aimed at binary package distributors
|
|
who know their target operating system well. The main
|
|
advantage of using this option is that the PostgreSQL package
|
|
won't need to be upgraded whenever any of the many local
|
|
daylight-saving time rules change. Another advantage is that
|
|
PostgreSQL can be cross-compiled<indexterm><primary>cross
|
|
compilation</primary></indexterm> more straightforwardly if the
|
|
time zone database files do not need to be built during the
|
|
installation.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>--without-zlib</option></term>
|
|
<listitem>
|
|
<para>
|
|
<indexterm>
|
|
<primary>zlib</primary>
|
|
</indexterm>
|
|
Prevents use of the <application>Zlib</> library. This disables
|
|
support for compressed archives in <application>pg_dump</application>
|
|
and <application>pg_restore</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 might arise. Currently, this option is
|
|
recommended for production installations only if you use GCC.
|
|
But you should always have it on if you are doing development work
|
|
or running a beta version.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>--enable-coverage</option></term>
|
|
<listitem>
|
|
<para>
|
|
If using GCC, all programs and libraries are compiled with
|
|
code coverage testing instrumentation. When run, they
|
|
generate files in the build directory with code coverage
|
|
metrics.
|
|
<![%standalone-ignore[See <xref linkend="regress-coverage">
|
|
for more information.]]> This option is for use only with GCC
|
|
and when doing development work.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>--enable-profiling</option></term>
|
|
<listitem>
|
|
<para>
|
|
If using GCC, all programs and libraries are compiled so they
|
|
can be profiled. On backend exit, a subdirectory will be created
|
|
that contains the <filename>gmon.out</> file for use in profiling.
|
|
This option is for use only with GCC and when doing development work.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>--enable-cassert</option></term>
|
|
<listitem>
|
|
<para>
|
|
Enables <firstterm>assertion</> checks in the server, which test for
|
|
many <quote>cannot happen</> conditions. This is invaluable for
|
|
code development purposes, but the tests can slow down the
|
|
server significantly.
|
|
Also, having the tests turned on won't necessarily enhance the
|
|
stability of your server! The assertion checks are not categorized
|
|
for severity, and so what might be a relatively harmless bug will
|
|
still lead to server restarts if it triggers an assertion
|
|
failure. This option is not recommended for production use, but
|
|
you should have it on for development work or when running a beta
|
|
version.
|
|
</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>
|
|
|
|
<varlistentry>
|
|
<term><option>--enable-dtrace</option></term>
|
|
<listitem>
|
|
<para>
|
|
<indexterm>
|
|
<primary>DTrace</primary>
|
|
</indexterm>
|
|
Compiles with support for the dynamic tracing tool DTrace.
|
|
Operating system support for DTrace is currently available in
|
|
Solaris and Mac OS X Leopard.
|
|
</para>
|
|
|
|
<para>
|
|
To point to the <command>dtrace</command> program, the
|
|
environment variable <envar>DTRACE</envar> can be set. This
|
|
will often be necessary because <command>dtrace</command> is
|
|
typically installed under <filename>/usr/sbin</filename>,
|
|
which might not be in the path. Additional command-line
|
|
options for the <command>dtrace</command> program can be
|
|
specified in the environment variable
|
|
<envar>DTRACEFLAGS</envar>.
|
|
</para>
|
|
|
|
<para>
|
|
To include DTrace support in a 64-bit binary, specify
|
|
<literal>DTRACEFLAGS="-64"</> to configure. For example,
|
|
using the GCC compiler:
|
|
<screen>
|
|
./configure CC='gcc -m64' --enable-dtrace DTRACEFLAGS='-64' ...
|
|
</screen>
|
|
Using Sun's compiler:
|
|
<screen>
|
|
./configure CC='/opt/SUNWspro/bin/cc -xtarget=native64' --enable-dtrace DTRACEFLAGS='-64' ...
|
|
</screen>
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
</variablelist>
|
|
</para>
|
|
|
|
<para>
|
|
If you prefer a C compiler different from the one
|
|
<filename>configure</filename> picks, you can set the
|
|
environment variable <envar>CC</> to the program of your choice.
|
|
By default, <filename>configure</filename> will pick
|
|
<filename>gcc</filename> if available, else the platform's
|
|
default (usually <filename>cc</>). Similarly, you can override the
|
|
default compiler flags if needed 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>
|
|
|
|
<para>
|
|
Here is a list of the significant variables that can be set in
|
|
this manner:
|
|
|
|
<variablelist>
|
|
<varlistentry>
|
|
<term><envar>BISON</envar></term>
|
|
<listitem>
|
|
<para>
|
|
Bison program
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><envar>CC</envar></term>
|
|
<listitem>
|
|
<para>
|
|
C compiler
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><envar>CFLAGS</envar></term>
|
|
<listitem>
|
|
<para>
|
|
options to pass to the C compiler
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><envar>CPP</envar></term>
|
|
<listitem>
|
|
<para>
|
|
C preprocessor
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><envar>CPPFLAGS</envar></term>
|
|
<listitem>
|
|
<para>
|
|
options to pass to the C preprocessor
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><envar>DTRACE</envar></term>
|
|
<listitem>
|
|
<para>
|
|
location of the <command>dtrace</command> program
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><envar>DTRACEFLAGS</envar></term>
|
|
<listitem>
|
|
<para>
|
|
options to pass to the <command>dtrace</command> program
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><envar>FLEX</envar></term>
|
|
<listitem>
|
|
<para>
|
|
Flex program
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><envar>LDFLAGS</envar></term>
|
|
<listitem>
|
|
<para>
|
|
options to pass to the link editor
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><envar>LDFLAGS_SL</envar></term>
|
|
<listitem>
|
|
<para>
|
|
linker options for shared library linking
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><envar>MSGFMT</envar></term>
|
|
<listitem>
|
|
<para>
|
|
<command>msgfmt</command> program for native language support
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><envar>PERL</envar></term>
|
|
<listitem>
|
|
<para>
|
|
Full path to the Perl interpreter. This will be used to
|
|
determine the dependencies for building PL/Perl.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><envar>PYTHON</envar></term>
|
|
<listitem>
|
|
<para>
|
|
Full path to the Python interpreter. This will be used to
|
|
determine the dependencies for building PL/Python.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><envar>TCLSH</envar></term>
|
|
<listitem>
|
|
<para>
|
|
Full path to the Tcl interpreter. This will be used to
|
|
determine the dependencies for building PL/Tcl, and it will
|
|
be substituted into Tcl scripts.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><envar>XML2_CONFIG</envar></term>
|
|
<listitem>
|
|
<para>
|
|
<command>xml2-config</command> program used to locate the
|
|
libxml installation.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
</variablelist>
|
|
</para>
|
|
</step>
|
|
|
|
<step>
|
|
<title>Build</title>
|
|
|
|
<para>
|
|
To start the build, type
|
|
<screen>
|
|
<userinput>gmake</userinput>
|
|
</screen>
|
|
(Remember to use <acronym>GNU</> <application>make</>.) The build
|
|
will take a few minutes depending on your
|
|
hardware. The last line displayed should be
|
|
<screen>
|
|
All of PostgreSQL is successfully made. Ready to install.
|
|
</screen>
|
|
</para>
|
|
</step>
|
|
|
|
<step>
|
|
<title>Regression Tests</title>
|
|
|
|
<indexterm>
|
|
<primary>regression test</primary>
|
|
</indexterm>
|
|
|
|
<para>
|
|
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 <productname>PostgreSQL</>
|
|
runs on your machine in the way the developers expected it
|
|
to. Type
|
|
<screen>
|
|
<userinput>gmake check</userinput>
|
|
</screen>
|
|
(This won't work as root; do it as an unprivileged user.)
|
|
<![%standalone-include[The file
|
|
<filename>src/test/regress/README</> and the
|
|
documentation contain]]>
|
|
<![%standalone-ignore[<xref linkend="regress"> contains]]>
|
|
detailed information about interpreting the test results. You can
|
|
repeat this test at any later time by issuing the same command.
|
|
</para>
|
|
</step>
|
|
|
|
<step id="install">
|
|
<title>Installing The Files</title>
|
|
|
|
<note>
|
|
<para>
|
|
If you are upgrading an existing system and are going to install
|
|
the new files over the old ones, be sure to back up
|
|
your data and shut down the old server before proceeding, as explained in
|
|
<xref linkend="install-upgrading"> above.
|
|
</para>
|
|
</note>
|
|
|
|
<para>
|
|
To install <productname>PostgreSQL</> enter
|
|
<screen>
|
|
<userinput>gmake install</userinput>
|
|
</screen>
|
|
This will install files into the directories that were specified
|
|
in <xref linkend="configure">. 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.
|
|
</para>
|
|
|
|
<para>
|
|
You can use <literal>gmake install-strip</literal> instead of
|
|
<literal>gmake install</literal> 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. <literal>install-strip</literal>
|
|
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.
|
|
</para>
|
|
|
|
<para>
|
|
The standard installation provides all the header files needed for client
|
|
application development as well as for server-side program
|
|
development, such as custom functions or data types written in C.
|
|
(Prior to <productname>PostgreSQL</> 8.0, a separate <literal>gmake
|
|
install-all-headers</> command was needed for the latter, but this
|
|
step has been folded into the standard install.)
|
|
</para>
|
|
|
|
<formalpara>
|
|
<title>Client-only installation:</title>
|
|
<para>
|
|
If you want to install only the client applications and
|
|
interface libraries, then you can use these commands:
|
|
<screen>
|
|
<userinput>gmake -C src/bin install</>
|
|
<userinput>gmake -C src/include install</>
|
|
<userinput>gmake -C src/interfaces install</>
|
|
<userinput>gmake -C doc install</>
|
|
</screen>
|
|
<filename>src/bin</> has a few binaries for server-only use,
|
|
but they are small.
|
|
</para>
|
|
</formalpara>
|
|
</step>
|
|
</procedure>
|
|
|
|
<formalpara>
|
|
<title>Registering <application>eventlog</> on <systemitem
|
|
class="osname">Windows</>:</title>
|
|
<para>
|
|
To register a <systemitem class="osname">Windows</> <application>eventlog</>
|
|
library with the operating system, issue this command after installation:
|
|
<screen>
|
|
<userinput>regsvr32 <replaceable>pgsql_library_directory</>/pgevent.dll</>
|
|
</screen>
|
|
This creates registry entries used by the event viewer.
|
|
</para>
|
|
</formalpara>
|
|
|
|
<formalpara>
|
|
<title>Uninstallation:</title>
|
|
<para>
|
|
To undo the installation use the command <command>gmake
|
|
uninstall</>. However, this will not remove any created directories.
|
|
</para>
|
|
</formalpara>
|
|
|
|
<formalpara>
|
|
<title>Cleaning:</title>
|
|
|
|
<para>
|
|
After the installation you can make room by removing the built
|
|
files from the source tree with the command <command>gmake
|
|
clean</>. This will preserve the files made by the <command>configure</command>
|
|
program, so that you can rebuild everything with <command>gmake</>
|
|
later on. To reset the source tree to the state in which it was
|
|
distributed, use <command>gmake distclean</>. If you are going to
|
|
build for several platforms within the same source tree you must do
|
|
this and re-configure for each build. (Alternatively, use
|
|
a separate build tree for each platform, so that the source tree
|
|
remains unmodified.)
|
|
</para>
|
|
</formalpara>
|
|
|
|
<para>
|
|
If you perform a build and then discover that your <command>configure</>
|
|
options were wrong, or if you change anything that <command>configure</>
|
|
investigates (for example, software upgrades), then it's a good
|
|
idea to do <command>gmake distclean</> before reconfiguring and
|
|
rebuilding. Without this, your changes in configuration choices
|
|
might not propagate everywhere they need to.
|
|
</para>
|
|
</sect1>
|
|
|
|
<sect1 id="install-post">
|
|
<title>Post-Installation Setup</title>
|
|
|
|
<sect2>
|
|
<title>Shared Libraries</title>
|
|
|
|
<indexterm>
|
|
<primary>shared library</primary>
|
|
</indexterm>
|
|
|
|
<para>
|
|
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
|
|
<emphasis>not</emphasis> necessary include <systemitem
|
|
class="osname">BSD/OS</>, <systemitem class="osname">FreeBSD</>,
|
|
<systemitem class="osname">HP-UX</>, <systemitem
|
|
class="osname">IRIX</>, <systemitem class="osname">Linux</>,
|
|
<systemitem class="osname">NetBSD</>, <systemitem
|
|
class="osname">OpenBSD</>, <systemitem class="osname">Tru64
|
|
UNIX</> (formerly <systemitem class="osname">Digital UNIX</>), and
|
|
<systemitem class="osname">Solaris</>.
|
|
</para>
|
|
|
|
<para>
|
|
The method to set the shared library search path varies between
|
|
platforms, but the most widely usable method is to set the
|
|
environment variable <envar>LD_LIBRARY_PATH</> like so: In Bourne
|
|
shells (<command>sh</>, <command>ksh</>, <command>bash</>, <command>zsh</>):
|
|
<programlisting>
|
|
LD_LIBRARY_PATH=/usr/local/pgsql/lib
|
|
export LD_LIBRARY_PATH
|
|
</programlisting>
|
|
or in <command>csh</> or <command>tcsh</>:
|
|
<programlisting>
|
|
setenv LD_LIBRARY_PATH /usr/local/pgsql/lib
|
|
</programlisting>
|
|
Replace <literal>/usr/local/pgsql/lib</> with whatever you set
|
|
<option><literal>--libdir</></> to in <xref linkend="configure">.
|
|
You should put these commands into a shell start-up file such as
|
|
<filename>/etc/profile</> or <filename>~/.bash_profile</>. Some
|
|
good information about the caveats associated with this method can
|
|
be found at <ulink
|
|
url="http://www.visi.com/~barr/ldpath.html"></ulink>.
|
|
</para>
|
|
|
|
<para>
|
|
On some systems it might be preferable to set the environment
|
|
variable <envar>LD_RUN_PATH</envar> <emphasis>before</emphasis>
|
|
building.
|
|
</para>
|
|
|
|
<para>
|
|
On <systemitem class="osname">Cygwin</systemitem>, put the library
|
|
directory in the <envar>PATH</envar> or move the
|
|
<filename>.dll</filename> files into the <filename>bin</filename>
|
|
directory.
|
|
</para>
|
|
|
|
<para>
|
|
If in doubt, refer to the manual pages of your system (perhaps
|
|
<command>ld.so</command> or <command>rld</command>). If you later
|
|
on get a message like
|
|
<screen>
|
|
psql: error in loading shared libraries
|
|
libpq.so.2.1: cannot open shared object file: No such file or directory
|
|
</screen>
|
|
then this step was necessary. Simply take care of it then.
|
|
</para>
|
|
|
|
<para>
|
|
<indexterm>
|
|
<primary>ldconfig</primary>
|
|
</indexterm>
|
|
If you are on <systemitem class="osname">BSD/OS</>, <systemitem
|
|
class="osname">Linux</>, or <systemitem class="osname">SunOS 4</>
|
|
and you have root access you can run:
|
|
<programlisting>
|
|
/sbin/ldconfig /usr/local/pgsql/lib
|
|
</programlisting>
|
|
(or equivalent directory) after installation to enable the
|
|
run-time linker to find the shared libraries faster. Refer to the
|
|
manual page of <command>ldconfig</> for more information. On
|
|
<systemitem class="osname">FreeBSD</>, <systemitem
|
|
class="osname">NetBSD</>, and <systemitem
|
|
class="osname">OpenBSD</> the command is:
|
|
<programlisting>
|
|
/sbin/ldconfig -m /usr/local/pgsql/lib
|
|
</programlisting>
|
|
instead. Other systems are not known to have an equivalent
|
|
command.
|
|
</para>
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title>Environment Variables</title>
|
|
|
|
<indexterm>
|
|
<primary><envar>PATH</envar></primary>
|
|
</indexterm>
|
|
|
|
<para>
|
|
If you installed into <filename>/usr/local/pgsql</> or some other
|
|
location that is not searched for programs by default, you should
|
|
add <filename>/usr/local/pgsql/bin</> (or whatever you set
|
|
<option><literal>--bindir</></> to in <xref linkend="configure">)
|
|
into your <envar>PATH</>. Strictly speaking, this is not
|
|
necessary, but it will make the use of <productname>PostgreSQL</>
|
|
much more convenient.
|
|
</para>
|
|
|
|
<para>
|
|
To do this, add the following to your shell start-up file, such as
|
|
<filename>~/.bash_profile</> (or <filename>/etc/profile</>, if you
|
|
want it to affect every user):
|
|
<programlisting>
|
|
PATH=/usr/local/pgsql/bin:$PATH
|
|
export PATH
|
|
</programlisting>
|
|
If you are using <command>csh</> or <command>tcsh</>, then use this command:
|
|
<programlisting>
|
|
set path = ( /usr/local/pgsql/bin $path )
|
|
</programlisting>
|
|
</para>
|
|
|
|
<para>
|
|
<indexterm>
|
|
<primary><envar>MANPATH</envar></primary>
|
|
</indexterm>
|
|
To enable your system to find the <application>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:
|
|
<programlisting>
|
|
MANPATH=/usr/local/pgsql/man:$MANPATH
|
|
export MANPATH
|
|
</programlisting>
|
|
</para>
|
|
|
|
<para>
|
|
The environment variables <envar>PGHOST</> and <envar>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 <envar>PGHOST</>. This
|
|
is not required, however: the settings can be communicated via command
|
|
line options to most client programs.
|
|
</para>
|
|
</sect2>
|
|
</sect1>
|
|
|
|
|
|
<![%standalone-include;[
|
|
<sect1 id="install-getting-started">
|
|
<title>Getting Started</title>
|
|
|
|
<para>
|
|
The following is a quick summary of how to get <productname>PostgreSQL</> up and
|
|
running once installed. The main documentation contains more information.
|
|
</para>
|
|
|
|
<procedure>
|
|
<step>
|
|
<para>
|
|
Create a user account for the <productname>PostgreSQL</>
|
|
server. This is the user the server will run as. For production
|
|
use you should create a separate, unprivileged account
|
|
(<quote>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.
|
|
<screen>
|
|
<userinput>adduser postgres</>
|
|
</screen>
|
|
</para>
|
|
</step>
|
|
|
|
<step>
|
|
<para>
|
|
Create a database installation with the <command>initdb</>
|
|
command. To run <command>initdb</> you must be logged in to your
|
|
<productname>PostgreSQL</> server account. It will not work as
|
|
root.
|
|
<screen>
|
|
root# <userinput>mkdir /usr/local/pgsql/data</>
|
|
root# <userinput>chown postgres /usr/local/pgsql/data</>
|
|
root# <userinput>su - postgres</>
|
|
postgres$ <userinput>/usr/local/pgsql/bin/initdb -D /usr/local/pgsql/data</>
|
|
</screen>
|
|
</para>
|
|
|
|
<para>
|
|
The <option>-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 <command>initdb</>, as
|
|
illustrated here.
|
|
</para>
|
|
</step>
|
|
|
|
<step>
|
|
<para>
|
|
At this point, if you did not use the <command>initdb</> <literal>-A</>
|
|
option, you might want to modify <filename>pg_hba.conf</> to control
|
|
local access to the server before you start it. The default is to
|
|
trust all local users.
|
|
</para>
|
|
</step>
|
|
|
|
<step>
|
|
<para>
|
|
The previous <command>initdb</> step should have told you how to
|
|
start up the database server. Do so now. The command should look
|
|
something like:
|
|
<programlisting>
|
|
/usr/local/pgsql/bin/postgres -D /usr/local/pgsql/data
|
|
</programlisting>
|
|
This will start the server in the foreground. To put the server
|
|
in the background use something like:
|
|
<programlisting>
|
|
nohup /usr/local/pgsql/bin/postgres -D /usr/local/pgsql/data \
|
|
</dev/null >>server.log 2>&1 </dev/null &
|
|
</programlisting>
|
|
</para>
|
|
|
|
<para>
|
|
To stop a server running in the background you can type:
|
|
<programlisting>
|
|
kill `cat /usr/local/pgsql/data/postmaster.pid`
|
|
</programlisting>
|
|
</para>
|
|
</step>
|
|
|
|
<step>
|
|
<para>
|
|
Create a database:
|
|
<screen>
|
|
<userinput>createdb testdb</>
|
|
</screen>
|
|
Then enter
|
|
<screen>
|
|
<userinput>psql testdb</>
|
|
</screen>
|
|
to connect to that database. At the prompt you can enter SQL
|
|
commands and start experimenting.
|
|
</para>
|
|
</step>
|
|
</procedure>
|
|
</sect1>
|
|
|
|
<sect1 id="install-whatnow">
|
|
<title>What Now?</title>
|
|
|
|
<para>
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>
|
|
The <productname>PostgreSQL</> distribution contains a
|
|
comprehensive documentation set, which you should read sometime.
|
|
After installation, the documentation can be accessed by
|
|
pointing your browser to
|
|
<filename>/usr/local/pgsql/doc/html/index.html</>, unless you
|
|
changed the installation directories.
|
|
</para>
|
|
|
|
<para>
|
|
The first few chapters of the main documentation are the Tutorial,
|
|
which should be your first reading if you are completely new to
|
|
<acronym>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.
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
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.
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
Run the regression tests against the installed server (using
|
|
<command>gmake installcheck</command>). If you didn't run the
|
|
tests before installation, you should definitely do it now. This
|
|
is also explained in the documentation.
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
By default, <productname>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 <varname>shared_buffers</varname> and
|
|
<varname>work_mem</varname>.
|
|
Other parameters mentioned in the documentation also affect
|
|
performance.
|
|
</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</para>
|
|
</sect1>
|
|
]]>
|
|
|
|
|
|
<sect1 id="supported-platforms">
|
|
<title>Supported Platforms</title>
|
|
|
|
<para>
|
|
A platform (that is, a CPU architecture and operating system combination)
|
|
is considered supported by the <productname>PostgreSQL</> development
|
|
community if the code contains provisions to work on that platform and
|
|
it has recently been verified to build and pass its regression tests
|
|
on that platform. Currently, most testing of platform compatibility
|
|
is done automatically by test machines in the
|
|
<ulink url="http://buildfarm.postgresql.org/">PostgreSQL Build Farm</ulink>.
|
|
If you are interested in using <productname>PostgreSQL</> on a platform
|
|
that is not represented in the build farm, but on which the code works
|
|
or can be made to work, you are strongly encouraged to set up a build
|
|
farm member machine so that continued compatibility can be assured.
|
|
</para>
|
|
|
|
<para>
|
|
In general, <productname>PostgreSQL</> can be expected to work on
|
|
these CPU architectures: x86, x86_64, IA64, PowerPC,
|
|
PowerPC 64, S/390, S/390x, Sparc, Sparc 64, Alpha, ARM, MIPS, MIPSEL, M68K,
|
|
and PA-RISC. Code support exists for M32R, NS32K, and VAX, but these
|
|
architectures are not known to have been tested recently. It is often
|
|
possible to build on an unsupported CPU type by configuring with
|
|
<option>--disable-spinlocks</option>, but performance will be poor.
|
|
</para>
|
|
|
|
<para>
|
|
<productname>PostgreSQL</> can be expected to work on these operating
|
|
systems: Linux (all recent distributions), Windows (Win2000 SP4 and later),
|
|
FreeBSD, OpenBSD, NetBSD, Mac OS X, AIX, HP/UX, IRIX, Solaris, Tru64 Unix,
|
|
and UnixWare. Other Unix-like systems may also work but are not currently
|
|
being tested. In most cases, all CPU architectures supported by
|
|
a given operating system will work. Look in the <filename>doc/</>
|
|
directory of the source distribution to see if there is a FAQ document
|
|
specific to your operating system, particularly if using an older system.
|
|
</para>
|
|
|
|
<para>
|
|
If you have installation problems on a platform that is known
|
|
to be supported according to recent build farm results, please report
|
|
it to <email>pgsql-bugs@postgresql.org</email>. If you are interested
|
|
in porting <productname>PostgreSQL</> to a new platform,
|
|
<email>pgsql-ports@postgresql.org</email> is the appropriate place
|
|
to discuss that.
|
|
</para>
|
|
</sect1>
|
|
|
|
</chapter>
|