1829 lines
64 KiB
Plaintext
1829 lines
64 KiB
Plaintext
<!-- $PostgreSQL: pgsql/doc/src/sgml/installation.sgml,v 1.205 2004/10/01 02:00:43 neilc 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.
|
|
</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/postmaster -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>gzip</> is needed to unpack the distribution in the
|
|
first place.<![%standalone-include;[ If you are reading this, you probably already got
|
|
past that hurdle.]]>
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
<indexterm>
|
|
<primary>readline</primary>
|
|
</indexterm>
|
|
|
|
The <acronym>GNU</> <productname>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>--without-readline</option> option for
|
|
<filename>configure</>. (On <productname>NetBSD</productname>,
|
|
the <filename>libedit</filename> library is
|
|
<productname>Readline</productname>-compatible and is used if
|
|
<filename>libreadline</filename> is not found.)
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
<indexterm>
|
|
<primary>installation</primary>
|
|
<secondary>on Windows</secondary>
|
|
</indexterm>
|
|
|
|
To build on <productname>Windows NT</> or <productname>Windows
|
|
2000</> you need the <productname>Cygwin</> and
|
|
<productname>cygipc</> packages. See the file
|
|
<filename>doc/FAQ_MSWIN</> for details.
|
|
</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 general 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 distutils module.
|
|
The distutils 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 Tcl installation.
|
|
</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 here: <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</>, or <application>PAM</>,
|
|
if you want to support authentication 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>bison</primary>
|
|
</indexterm>
|
|
<indexterm>
|
|
<primary>yacc</primary>
|
|
</indexterm>
|
|
|
|
<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>yacc</>
|
|
programs can sometimes be used, but doing so requires extra
|
|
effort and is not recommended. Other <application>lex</>
|
|
programs will definitely not work.
|
|
</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 for 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>.
|
|
Use a mirror if possible. 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>If You Are Upgrading</title>
|
|
|
|
<indexterm zone="install-upgrading">
|
|
<primary>upgrading</primary>
|
|
</indexterm>
|
|
|
|
<para>
|
|
The internal data storage format changes with new releases of
|
|
<productname>PostgreSQL</>. Therefore, if you are upgrading an
|
|
existing installation that does not have a version number
|
|
<quote>&majorversion;.x</quote>, you must back up and restore your
|
|
data as shown here. 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>
|
|
|
|
<procedure>
|
|
<step>
|
|
<para>
|
|
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
|
|
<filename>/usr/local/pgsql/data/pg_hba.conf</> (or equivalent) to
|
|
disallow access from everyone except you.
|
|
</para>
|
|
</step>
|
|
|
|
<step>
|
|
<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>
|
|
<application>pg_dumpall</application> does not
|
|
save large objects. Check
|
|
<![%standalone-include[the documentation]]>
|
|
<![%standalone-ignore[<xref linkend="backup-dump-caveats">]]>
|
|
if you need to do this.
|
|
</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>
|
|
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:
|
|
<screen>
|
|
<userinput>kill -INT `cat /usr/local/pgsql/data/postmaster.pid | sed 1q`</>
|
|
</screen>
|
|
Versions prior to 7.0 do not have this
|
|
<filename>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 <userinput>ps ax | grep postmaster</>, and
|
|
supply it to the <command>kill</> command.
|
|
</para>
|
|
|
|
<para>
|
|
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. Another possibility is <userinput>pg_ctl stop</>.
|
|
</para>
|
|
</step>
|
|
|
|
<step>
|
|
<para>
|
|
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:
|
|
<screen>
|
|
<userinput>mv /usr/local/pgsql /usr/local/pgsql.old</>
|
|
</screen>
|
|
</para>
|
|
</step>
|
|
</procedure>
|
|
|
|
<para>
|
|
After you have installed <productname>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).
|
|
<programlisting>
|
|
<userinput>/usr/local/pgsql/bin/initdb -D /usr/local/pgsql/data</>
|
|
<userinput>/usr/local/pgsql/bin/postmaster -D /usr/local/pgsql/data</>
|
|
</programlisting>
|
|
Finally, restore your data with
|
|
<screen>
|
|
<userinput>/usr/local/pgsql/bin/psql -d template1 -f <replaceable>outputfile</></userinput>
|
|
</screen>
|
|
using the <emphasis>new</> <application>psql</>.
|
|
</para>
|
|
|
|
<para>
|
|
These topics are discussed at length in <![%standalone-include[the
|
|
documentation,]]> <![%standalone-ignore[<xref
|
|
linkend="migration">,]]> which you are encouraged to read in any
|
|
case.
|
|
</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>--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</title>
|
|
|
|
<para>
|
|
To start the build, type
|
|
<screen>
|
|
<userinput>gmake</userinput>
|
|
</screen>
|
|
(Remember to use <acronym>GNU</> <application>make</>.) The build
|
|
may take anywhere from 5 minutes to half an hour 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, then you should have backed up
|
|
your data and shut down the old server by now, 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 only the header files needed for client
|
|
application development. If you plan to do any server-side program
|
|
development (such as custom functions or data types written in C),
|
|
then you may want to install the entire <productname>PostgreSQL</>
|
|
include tree into your target include directory. To do that, enter
|
|
<screen>
|
|
<userinput>gmake install-all-headers</userinput>
|
|
</screen>
|
|
This adds a megabyte or two to the installation footprint, and is only
|
|
useful if you don't plan to keep the whole source tree around for
|
|
reference. (If you do, you can just use the source's include
|
|
directory when building server-side software.)
|
|
</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>
|
|
</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 from the same source tree you must do
|
|
this and re-configure for each build.
|
|
</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
|
|
may 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>
|
|
The previous 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/postmaster -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/postmaster -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>
|
|
|
|
<para>
|
|
In order to allow TCP/IP connections (rather than only Unix
|
|
domain socket ones) you need to pass the <option>-i</> option to
|
|
<filename>postmaster</>.
|
|
</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>
|
|
<productname>PostgreSQL</> has been verified by the developer
|
|
community to work on the platforms listed below. A supported
|
|
platform generally means that <productname>PostgreSQL</> builds and
|
|
installs according to these instructions and that the regression
|
|
tests pass.
|
|
</para>
|
|
|
|
<note>
|
|
<para>
|
|
If you are having problems with the installation on a supported
|
|
platform, please write to <email>pgsql-bugs@postgresql.org</email>
|
|
or <email>pgsql-ports@postgresql.org</email>, not to the people
|
|
listed here.
|
|
</para>
|
|
</note>
|
|
|
|
<informaltable>
|
|
<tgroup cols="5">
|
|
<thead>
|
|
<row>
|
|
<entry><acronym>OS</acronym></entry>
|
|
<entry>Processor</entry>
|
|
<entry>Version</entry>
|
|
<entry>Reported</entry>
|
|
<entry>Remarks</entry>
|
|
</row>
|
|
</thead>
|
|
<tbody>
|
|
<row>
|
|
<entry><systemitem class="osname">AIX</></entry>
|
|
<entry><systemitem>RS6000</></entry>
|
|
<entry>7.4</entry>
|
|
<entry>2003-10-25,
|
|
Hans-Jürgen Schönig (<email>hs@cybertec.at</email>)</entry>
|
|
<entry>see also <filename>doc/FAQ_AIX</filename></entry>
|
|
</row>
|
|
<row>
|
|
<entry><systemitem class="osname">BSD/OS</></entry>
|
|
<entry><systemitem>x86</></entry>
|
|
<entry>7.4</entry>
|
|
<entry>2003-10-24,
|
|
Bruce Momjian (<email>pgman@candle.pha.pa.us</email>)</entry>
|
|
<entry>4.3</entry>
|
|
</row>
|
|
<row>
|
|
<entry><systemitem class="osname">FreeBSD</></entry>
|
|
<entry><systemitem>Alpha</></entry>
|
|
<entry>7.4</entry>
|
|
<entry>2003-10-25,
|
|
Peter Eisentraut (<email>peter_e@gmx.net</email>)</entry>
|
|
<entry>4.8</entry>
|
|
</row>
|
|
<row>
|
|
<entry><systemitem class="osname">FreeBSD</></entry>
|
|
<entry><systemitem>x86</></entry>
|
|
<entry>7.4</entry>
|
|
<entry>2003-10-24,
|
|
Peter Eisentraut (<email>peter_e@gmx.net</email>)</entry>
|
|
<entry>4.9</entry>
|
|
</row>
|
|
<row>
|
|
<entry><systemitem class="osname">HP-UX</></entry>
|
|
<entry><systemitem>PA-RISC</></entry>
|
|
<entry>7.4</entry>
|
|
<entry>
|
|
2003-10-31, 10.20, Tom Lane (<email>tgl@sss.pgh.pa.us</email>);
|
|
2003-11-04, 11.00, Peter Eisentraut (<email>peter_e@gmx.net</email>)
|
|
</entry>
|
|
<entry><command>gcc</> and <command>cc</>; see also <filename>doc/FAQ_HPUX</filename></entry>
|
|
</row>
|
|
<row>
|
|
<entry><systemitem class="osname">IRIX</></entry>
|
|
<entry><systemitem>MIPS</></entry>
|
|
<entry>7.4</entry>
|
|
<entry>2003-11-12,
|
|
Robert E. Bruccoleri (<email>bruc@stone.congenomics.com</email>)</entry>
|
|
<entry>6.5.20, <command>cc</command> only</entry>
|
|
</row>
|
|
<row>
|
|
<entry><systemitem class="osname">Linux</></entry>
|
|
<entry><systemitem>Alpha</></entry>
|
|
<entry>7.4</entry>
|
|
<entry>2003-10-25,
|
|
Noèl Köthe (<email>noel@debian.org</email>)</entry>
|
|
<entry>2.4</entry>
|
|
</row>
|
|
<row>
|
|
<entry><systemitem class="osname">Linux</></entry>
|
|
<entry><systemitem>arm41</></entry>
|
|
<entry>7.4</entry>
|
|
<entry>2003-10-25,
|
|
Noèl Köthe (<email>noel@debian.org</email>)</entry>
|
|
<entry>2.4</entry>
|
|
</row>
|
|
<row>
|
|
<entry><systemitem class="osname">Linux</></entry>
|
|
<entry><systemitem>Itanium</></entry>
|
|
<entry>7.4</entry>
|
|
<entry>2003-10-25,
|
|
Noèl Köthe (<email>noel@debian.org</email>)</entry>
|
|
<entry>2.4</entry>
|
|
</row>
|
|
<row>
|
|
<entry><systemitem class="osname">Linux</></entry>
|
|
<entry><systemitem>m68k</></entry>
|
|
<entry>7.4</entry>
|
|
<entry>2003-10-25,
|
|
Noèl Köthe (<email>noel@debian.org</email>)</entry>
|
|
<entry>2.4</entry>
|
|
</row>
|
|
<row>
|
|
<entry><systemitem class="osname">Linux</></entry>
|
|
<entry><systemitem>MIPS</></entry>
|
|
<entry>7.4</entry>
|
|
<entry>2003-10-25,
|
|
Noèl Köthe (<email>noel@debian.org</email>)</entry>
|
|
<entry>2.4</entry>
|
|
</row>
|
|
<row>
|
|
<entry><systemitem class="osname">Linux</></entry>
|
|
<entry><systemitem>Opteron</></entry>
|
|
<entry>7.4</entry>
|
|
<entry>2003-11-01,
|
|
Jani Averbach (<email>jaa@cc.jyu.fi</email>)</entry>
|
|
<entry>2.6</entry>
|
|
</row>
|
|
<row>
|
|
<entry><systemitem class="osname">Linux</></entry>
|
|
<entry><systemitem>PPC</></entry>
|
|
<entry>7.4</entry>
|
|
<entry>2003-10-25,
|
|
Noèl Köthe (<email>noel@debian.org</email>)</entry>
|
|
<entry></entry>
|
|
</row>
|
|
<row>
|
|
<entry><systemitem class="osname">Linux</></entry>
|
|
<entry><systemitem>S/390</></entry>
|
|
<entry>7.4</entry>
|
|
<entry>2003-10-25,
|
|
Noèl Köthe (<email>noel@debian.org</email>)</entry>
|
|
<entry>2.4</entry>
|
|
</row>
|
|
<row>
|
|
<entry><systemitem class="osname">Linux</></entry>
|
|
<entry><systemitem>Sparc</></entry>
|
|
<entry>7.4</entry>
|
|
<entry>2003-10-24,
|
|
Peter Eisentraut (<email>peter_e@gmx.net</email>)</entry>
|
|
<entry>2.4, 32-bit</entry>
|
|
</row>
|
|
<row>
|
|
<entry><systemitem class="osname">Linux</></entry>
|
|
<entry><systemitem>x86</></entry>
|
|
<entry>7.4</entry>
|
|
<entry>2003-10-24,
|
|
Peter Eisentraut (<email>peter_e@gmx.net</email>)</entry>
|
|
<entry>2.4</entry>
|
|
</row>
|
|
<row>
|
|
<entry><systemitem class="osname">Mac OS X</></entry>
|
|
<entry><systemitem>PPC</></entry>
|
|
<entry>7.4</entry>
|
|
<entry>2003-10-24,
|
|
10.2.8, Adam Witney (<email>awitney@sghms.ac.uk</email>),
|
|
10.3, Marko Karppinen (<email>marko@karppinen.fi</email>)</entry>
|
|
<entry></entry>
|
|
</row>
|
|
<row>
|
|
<entry><systemitem class="osname">NetBSD</></entry>
|
|
<entry><systemitem>arm32</></entry>
|
|
<entry>7.4</entry>
|
|
<entry>2003-11-12,
|
|
Patrick Welche (<email>prlw1@newn.cam.ac.uk</email>)</entry>
|
|
<entry>1.6ZE/acorn32</entry>
|
|
</row>
|
|
<row>
|
|
<entry><systemitem class="osname">NetBSD</></entry>
|
|
<entry><systemitem>Sparc</></entry>
|
|
<entry>7.4.1</entry>
|
|
<entry>2003-11-26,
|
|
Peter Eisentraut (<email>peter_e@gmx.net</email>)</entry>
|
|
<entry>1.6.1, 32-bit</entry>
|
|
</row>
|
|
<row>
|
|
<entry><systemitem class="osname">NetBSD</></entry>
|
|
<entry><systemitem>x86</></entry>
|
|
<entry>7.4</entry>
|
|
<entry>2003-10-24,
|
|
Peter Eisentraut (<email>peter_e@gmx.net</email>)</entry>
|
|
<entry>1.6</entry>
|
|
</row>
|
|
<row>
|
|
<entry><systemitem class="osname">OpenBSD</></entry>
|
|
<entry><systemitem>Sparc</></entry>
|
|
<entry>7.4</entry>
|
|
<entry>2003-11-01,
|
|
Peter Eisentraut (<email>peter_e@gmx.net</email>)</entry>
|
|
<entry>3.4</entry>
|
|
</row>
|
|
<row>
|
|
<entry><systemitem class="osname">OpenBSD</></entry>
|
|
<entry><systemitem>x86</></entry>
|
|
<entry>7.4</entry>
|
|
<entry>2003-10-24,
|
|
Peter Eisentraut (<email>peter_e@gmx.net</email>)</entry>
|
|
<entry>3.2</entry>
|
|
</row>
|
|
<row>
|
|
<entry><systemitem class="osname">Solaris</></entry>
|
|
<entry><systemitem>Sparc</></entry>
|
|
<entry>7.4</entry>
|
|
<entry>2003-10-26,
|
|
Christopher Browne (<email>cbbrowne@libertyrms.info</email>)</entry>
|
|
<entry>2.8; see also <filename>doc/FAQ_Solaris</filename></entry>
|
|
</row>
|
|
<row>
|
|
<entry><systemitem class="osname">Solaris</></entry>
|
|
<entry><systemitem>x86</></entry>
|
|
<entry>7.4</entry>
|
|
<entry>2003-10-26,
|
|
Kurt Roeckx (<email>Q@ping.be</email>)</entry>
|
|
<entry>2.6; see also <filename>doc/FAQ_Solaris</filename></entry>
|
|
</row>
|
|
<row>
|
|
<entry><systemitem class="osname">Tru64 UNIX</></entry>
|
|
<entry><systemitem>Alpha</></entry>
|
|
<entry>7.4</entry>
|
|
<entry>2003-10-25, 5.1b, Peter Eisentraut (<email>peter_e@gmx.net</email>);
|
|
2003-10-29, 4.0g, Alessio Bragadini (<email>alessio@albourne.com</email>)</entry>
|
|
<entry></entry>
|
|
</row>
|
|
<row>
|
|
<entry><systemitem class="osname">UnixWare</></entry>
|
|
<entry><systemitem>x86</></entry>
|
|
<entry>7.4</entry>
|
|
<entry>2003-11-03, Larry Rosenman (<email>ler@lerctr.org</email>)</entry>
|
|
<entry>7.1.3; join test may fail, see also <filename>doc/FAQ_SCO</filename></entry>
|
|
</row>
|
|
<row>
|
|
<entry><systemitem class="osname">Windows with <application>Cygwin</application></></entry>
|
|
<entry><systemitem>x86</></entry>
|
|
<entry>7.4</entry>
|
|
<entry>2003-10-24,
|
|
Peter Eisentraut (<email>peter_e@gmx.net</email>)</entry>
|
|
<entry>see <filename>doc/FAQ_MSWIN</filename></entry>
|
|
</row>
|
|
<row>
|
|
<entry><systemitem class="osname">Windows</></entry>
|
|
<entry><systemitem>x86</></entry>
|
|
<entry>7.4</entry>
|
|
<entry>2003-10-27,
|
|
Dave Page (<email>dpage@vale-housing.co.uk</email>)</entry>
|
|
<entry>
|
|
native is client-side only,
|
|
<![%standalone-include[see documentation]]>
|
|
<![%standalone-ignore[see <xref linkend="install-win32">]]>
|
|
</entry>
|
|
</row>
|
|
</tbody>
|
|
</tgroup>
|
|
</informaltable>
|
|
|
|
<formalpara>
|
|
<title>Unsupported Platforms:</title>
|
|
<para>
|
|
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 <emphasis>could</> be supported if given
|
|
some attention.
|
|
</para>
|
|
</formalpara>
|
|
|
|
<informaltable>
|
|
<tgroup cols="5">
|
|
<thead>
|
|
<row>
|
|
<entry><acronym>OS</acronym></entry>
|
|
<entry>Processor</entry>
|
|
<entry>Version</entry>
|
|
<entry>Reported</entry>
|
|
<entry>Remarks</entry>
|
|
</row>
|
|
</thead>
|
|
|
|
<tbody>
|
|
<row>
|
|
<entry><systemitem class="osname">BeOS</></entry>
|
|
<entry><systemitem>x86</></entry>
|
|
<entry>7.2</entry>
|
|
<entry>2001-11-29,
|
|
Cyril Velter (<email>cyril.velter@libertysurf.fr</email>)</entry>
|
|
<entry>needs updates to semaphore code</entry>
|
|
</row>
|
|
<row>
|
|
<entry><systemitem class="osname">Linux</></entry>
|
|
<entry><systemitem>PlayStation 2</></entry>
|
|
<entry>7.4</entry>
|
|
<entry>2003-11-02,
|
|
Peter Eisentraut (<email>peter_e@gmx.net</email>)</entry>
|
|
<entry>
|
|
needs new <filename>config.guess</filename>,
|
|
<option>--disable-spinlocks</option>
|
|
</entry>
|
|
</row>
|
|
<row>
|
|
<entry><systemitem class="osname">Linux</></entry>
|
|
<entry><systemitem>PA-RISC</></entry>
|
|
<entry>7.4</entry>
|
|
<entry>2003-10-25,
|
|
Noèl Köthe (<email>noel@debian.org</email>)</entry>
|
|
<entry>needs <option>--disable-spinlocks</option>, otherwise OK</entry>
|
|
</row>
|
|
<row>
|
|
<entry><systemitem class="osname">NetBSD</></entry>
|
|
<entry><systemitem>Alpha</></entry>
|
|
<entry>7.2</entry>
|
|
<entry>2001-11-20,
|
|
Thomas Thai (<email>tom@minnesota.com</email>)</entry>
|
|
<entry>1.5W</entry>
|
|
</row>
|
|
<row>
|
|
<entry><systemitem class="osname">NetBSD</></entry>
|
|
<entry><systemitem>MIPS</></entry>
|
|
<entry>7.2.1</entry>
|
|
<entry>2002-06-13,
|
|
Warwick Hunter (<email>whunter@agile.tv</email>)</entry>
|
|
<entry>1.5.3</entry>
|
|
</row>
|
|
<row>
|
|
<entry><systemitem class="osname">NetBSD</></entry>
|
|
<entry><systemitem>PPC</></entry>
|
|
<entry>7.2</entry>
|
|
<entry>2001-11-28,
|
|
Bill Studenmund (<email>wrstuden@netbsd.org</email>)</entry>
|
|
<entry>1.5</entry>
|
|
</row>
|
|
<row>
|
|
<entry><systemitem class="osname">NetBSD</></entry>
|
|
<entry><systemitem>VAX</></entry>
|
|
<entry>7.1</entry>
|
|
<entry>2001-03-30,
|
|
Tom I. Helbekkmo (<email>tih@kpnQwest.no</email>)</entry>
|
|
<entry>1.5</entry>
|
|
</row>
|
|
<row>
|
|
<entry><systemitem class="osname">QNX 4 RTOS</></entry>
|
|
<entry><systemitem>x86</></entry>
|
|
<entry>7.2</entry>
|
|
<entry>2001-12-10,
|
|
Bernd Tegge (<email>tegge@repas-aeg.de</email>)
|
|
</entry>
|
|
<entry>needs updates to semaphore code;
|
|
see also <filename>doc/FAQ_QNX4</filename></entry>
|
|
</row>
|
|
<row>
|
|
<entry><systemitem class="osname">QNX RTOS v6</></entry>
|
|
<entry><systemitem>x86</></entry>
|
|
<entry>7.2</entry>
|
|
<entry>2001-11-20, Igor Kovalenko (<email>Igor.Kovalenko@motorola.com</email>)</entry>
|
|
<entry>patches available in archives, but too late for 7.2</entry>
|
|
</row>
|
|
<row>
|
|
<entry><systemitem class="osname">SCO OpenServer</></entry>
|
|
<entry><systemitem>x86</></entry>
|
|
<entry>7.3.1</entry>
|
|
<entry>2002-12-11,
|
|
Shibashish Satpathy (<email>shib@postmark.net</>)</entry>
|
|
<entry>5.0.4, <command>gcc</>; see also <filename>doc/FAQ_SCO</filename></entry>
|
|
</row>
|
|
<row>
|
|
<entry><systemitem class="osname">SunOS 4</></entry>
|
|
<entry><systemitem>Sparc</></entry>
|
|
<entry>7.2</entry>
|
|
<entry>2001-12-04, Tatsuo Ishii (<email>t-ishii@sra.co.jp</email>)</entry>
|
|
<entry></entry>
|
|
</row>
|
|
</tbody>
|
|
</tgroup>
|
|
</informaltable>
|
|
</sect1>
|
|
|
|
</chapter>
|
|
|
|
<!-- Keep this comment at the end of the file
|
|
Local variables:
|
|
mode:sgml
|
|
sgml-omittag:nil
|
|
sgml-shorttag:t
|
|
sgml-minimize-attributes:nil
|
|
sgml-always-quote-attributes:t
|
|
sgml-indent-step:1
|
|
sgml-indent-tabs-mode:nil
|
|
sgml-indent-data:t
|
|
sgml-parent-document:nil
|
|
sgml-default-dtd-file:"./reference.ced"
|
|
sgml-exposed-tags:nil
|
|
sgml-local-catalogs:("/usr/share/sgml/catalog")
|
|
sgml-local-ecat-files:nil
|
|
End:
|
|
-->
|