mirror of
https://github.com/postgres/postgres.git
synced 2025-05-03 22:24:49 +03:00
1843 lines
63 KiB
Plaintext
1843 lines
63 KiB
Plaintext
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/installation.sgml,v 1.78 2002/06/15 02:41:56 thomas Exp $ -->
|
|
|
|
<chapter id="installation">
|
|
<title><![%standalone-include[<productname>PostgreSQL</>]]>
|
|
Installation Instructions</title>
|
|
|
|
<indexterm zone="installation">
|
|
<primary>installation</primary>
|
|
</indexterm>
|
|
|
|
<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 prerequisites exist 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 GNU 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. 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>flex</primary>
|
|
</indexterm>
|
|
<indexterm>
|
|
<primary>bison</primary>
|
|
</indexterm>
|
|
<indexterm>
|
|
<primary>yacc</primary>
|
|
</indexterm>
|
|
|
|
<acronym>GNU</> <application>Flex</> and <application>Bison</> are
|
|
needed to build from scratch, but they are
|
|
<emphasis>not</> required when building from a released source
|
|
package because pre-generated output files are included in released
|
|
packages. You will
|
|
need these programs only when building from a CVS tree 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.28 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>
|
|
|
|
<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>
|
|
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
|
|
30 MB for the source tree during compilation and about 10 MB for the
|
|
installation directory. An empty database cluster takes about 20 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 an extra 20 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/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>
|
|
</indexterm>
|
|
|
|
To dump 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
|
|
<command>pg_dumpall</>.
|
|
</para>
|
|
|
|
<para>
|
|
<command>pg_dumpall</command> does not
|
|
save large objects. Check
|
|
<![%standalone-include[the <citetitle>Administrator's Guide</>]]>
|
|
<![%standalone-ignore[<xref linkend="backup-dump-caveats">]]>
|
|
if you need to do this.
|
|
</para>
|
|
|
|
<para>
|
|
Make sure that you use the <command>pg_dumpall</> command
|
|
from the version you are currently running. &version;'s
|
|
<command>pg_dumpall</> should not be used on older databases.
|
|
</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`</>
|
|
</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>
|
|
You can also install the new version in parallel with the old one
|
|
to decrease the downtime. These topics are discussed at length in
|
|
<![%standalone-include[the <citetitle>Administrator's Guide</>,]]>
|
|
<![%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.
|
|
</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.
|
|
</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>--docdir=<replaceable>DIRECTORY</></option></term>
|
|
<listitem>
|
|
<para>
|
|
Documentation files, except <quote>man</> pages, will be
|
|
installed into this directory. The default is
|
|
<filename><replaceable>PREFIX</>/doc</>.
|
|
</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>
|
|
</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>. Second, the
|
|
installation layout of the C and C++ header files has been
|
|
reorganized in the 7.2 release. The public 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 <citetitle>Programmer's Guide</citetitle> for
|
|
information about how to get at the header files for each interface.
|
|
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-recode</option></term>
|
|
<listitem>
|
|
<para>
|
|
Enables single-byte character set recode support. See
|
|
<![%standalone-include[the <citetitle>Administrator's Guide</citetitle>]]>
|
|
<![%standalone-ignore[<xref linkend="recode">]]> about this feature.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>--enable-multibyte</option></term>
|
|
<listitem>
|
|
<para>
|
|
Allows the use of multibyte character encodings (including Unicode)
|
|
and character set encoding conversion. Read
|
|
<![%standalone-include[the <citetitle>Administrator's Guide</citetitle>]]>
|
|
<![%standalone-ignore[<xref linkend="multibyte">]]>
|
|
for details.
|
|
</para>
|
|
|
|
<para>
|
|
Note that some interfaces (such as Tcl or Java) expect all character
|
|
strings to be in Unicode, so this option will be required to correctly
|
|
support these interfaces.
|
|
</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>
|
|
|
|
<comment>
|
|
The list of provided translations should be shown somewhere.
|
|
</comment>
|
|
|
|
<para>
|
|
To use this option, you will need an implementation of the
|
|
<application>gettext</> API. 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://www.postgresql.org/~petere/gettext.html"
|
|
></ulink>. If
|
|
you are using the <application>gettext</> implementation in the GNU 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>
|
|
|
|
<comment>
|
|
The download location should be moved.
|
|
</comment>
|
|
|
|
</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-CXX</option></term>
|
|
<listitem>
|
|
<para>
|
|
Build the C++ interface library.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>--with-perl</option></term>
|
|
<listitem>
|
|
<para>
|
|
Build the Perl interface module. The Perl interface
|
|
will be installed at the usual place for Perl modules
|
|
(typically under <filename>/usr/lib/perl</filename>), so you
|
|
must have root access to perform the installation step (see
|
|
<xref linkend="install">). You need to have Perl 5 installed to
|
|
use this option.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>--with-python</option></term>
|
|
<listitem>
|
|
<para>
|
|
Build the Python interface module. You need to have root
|
|
access to be able to install the Python module at its default
|
|
place
|
|
(<filename>/usr/lib/python<replaceable>x</>.<replaceable>y</></>).
|
|
To be able to use this option, you must have Python installed
|
|
and your system needs to support shared libraries. If you
|
|
instead want to build a new complete interpreter binary, you
|
|
will have to do it manually.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>--with-tcl</option></term>
|
|
<listitem>
|
|
<para>
|
|
Builds components that require Tcl/Tk, which are
|
|
<application>libpgtcl</>, <application>pgtclsh</>,
|
|
<application>pgtksh</application>, <application>PgAccess</>,
|
|
and <application>PL/Tcl</>. But see below about
|
|
<option>--without-tk</>.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>--without-tk</option></term>
|
|
<listitem>
|
|
<para>
|
|
If you specify <option>--with-tcl</> and this option, then
|
|
programs that require <productname>Tk</>
|
|
(<application>pgtksh</> and <application>PgAccess</>) will be
|
|
excluded.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>--with-tclconfig=<replaceable>DIRECTORY</replaceable></option></term>
|
|
<term><option>--with-tkconfig=<replaceable>DIRECTORY</replaceable></option></term>
|
|
<listitem>
|
|
<para>
|
|
Tcl/Tk installs the files <filename>tclConfig.sh</filename> and
|
|
<filename>tkConfig.sh</filename>, which contain
|
|
configuration information needed to build modules
|
|
interfacing to Tcl or Tk. These files are normally found
|
|
automatically at their well-known locations, but if you want to
|
|
use a different version of Tcl or Tk you can specify the
|
|
directory in which to find them.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>--enable-odbc</option></term>
|
|
<listitem>
|
|
<para>
|
|
Build the ODBC driver. By default, the driver will be independent
|
|
of a driver manager. To work better with a driver manager already
|
|
installed on your system, use one of the following options in addition
|
|
to this one. More information can be found in the
|
|
<citetitle>Programmer's Guide</citetitle>.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>--with-iodbc</option></term>
|
|
<listitem>
|
|
<para>
|
|
Build the ODBC driver for use with <productname>iODBC</>.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>--with-unixodbc</option></term>
|
|
<listitem>
|
|
<para>
|
|
Build the ODBC driver for use with <productname>unixODBC</>.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>--with-odbcinst=<replaceable>DIRECTORY</></option></term>
|
|
<listitem>
|
|
<para>
|
|
Specifies the directory where the ODBC driver will expect its
|
|
<filename>odbcinst.ini</> configuration file. The default is
|
|
<filename>/usr/local/pgsql/etc</filename> or whatever you
|
|
specified as <option>--sysconfdir</option>. It should be
|
|
arranged that the driver reads the same file as the driver
|
|
manager.
|
|
</para>
|
|
|
|
<para>
|
|
If either the option <option>--with-iodbc</option> or the
|
|
option <option>--with-unixodbc</option> is used, this option
|
|
will be ignored because in that case the driver manager
|
|
handles the location of the configuration file.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>--with-java</option></term>
|
|
<listitem>
|
|
<para>
|
|
Build the <acronym>JDBC</acronym> driver and associated Java
|
|
packages. This option requires
|
|
<application>Ant</application> to be installed (as well as a
|
|
<acronym>JDK</acronym>, of course). Refer to the
|
|
<acronym>JDBC</acronym> driver documentation in the
|
|
<citetitle>Programmer's Guide</citetitle> for more
|
|
information.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>--with-krb4<optional>=<replaceable>DIRECTORY</></></option></term>
|
|
<term><option>--with-krb5<optional>=<replaceable>DIRECTORY</></></option></term>
|
|
<listitem>
|
|
<para>
|
|
Build with support for Kerberos authentication. You can use
|
|
either Kerberos version 4 or 5, but not both. The
|
|
<replaceable>DIRECTORY</> argument specifies the root
|
|
directory of the Kerberos installation;
|
|
<filename>/usr/athena</> is assumed as default. If the
|
|
relevant header files and libraries are not under a common
|
|
parent directory, then you must use the
|
|
<option>--with-includes</> and <option>--with-libraries</>
|
|
options in addition to this option. If, on the other hand,
|
|
the required files are in a location that is searched by
|
|
default (e.g., <filename>/usr/lib</>), then you can leave off
|
|
the argument.
|
|
</para>
|
|
|
|
<para>
|
|
<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<optional>=<replaceable>DIRECTORY</></></option></term>
|
|
<listitem>
|
|
<para>
|
|
Build with support for <acronym>SSL</> (encrypted) connections.
|
|
This requires the <productname>OpenSSL</> package to be installed.
|
|
The <replaceable>DIRECTORY</> argument specifies the
|
|
root directory of the <productname>OpenSSL</> installation; the
|
|
default is <filename>/usr/local/ssl</>.
|
|
</para>
|
|
|
|
<para>
|
|
<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</> (Pluggable Authentication Modules)
|
|
support.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>--enable-syslog</option></term>
|
|
<listitem>
|
|
<para>
|
|
Enables the <productname>PostgreSQL</> server to use the
|
|
<systemitem>syslog</> logging facility. (Using this option does not mean
|
|
that you must log with <systemitem>syslog</> or even that it will be done
|
|
by default, it simply makes it possible to turn that option
|
|
on at run time.)
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>--without-readline</option></term>
|
|
<listitem>
|
|
<para>
|
|
Prevents the use of the Readline library. This disables
|
|
command-line editing and history in
|
|
<application>psql</application>, so it is not recommended.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>--without-zlib</option></term>
|
|
<listitem>
|
|
<para>
|
|
Prevents the use of the 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 or C++ compiler different from the one
|
|
<filename>configure</filename> picks then you can set the
|
|
environment variables <envar>CC</> or <envar>CXX</envar>,
|
|
respectively, to the program of your choice. Similarly, you can
|
|
override the default compiler flags with the <envar>CFLAGS</envar>
|
|
and <envar>CXXFLAGS</envar> variables. For example:
|
|
<screen>
|
|
<userinput>env CC=/opt/bin/gcc CFLAGS='-O2 -pipe' ./configure</>
|
|
</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.)
|
|
It is possible that some tests fail, due to differences in error
|
|
message wording or floating point results.
|
|
<![%standalone-include[The file
|
|
<filename>src/test/regress/README</> and the
|
|
<citetitle>Administrator's Guide</citetitle> 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>
|
|
If you built the Perl or Python interfaces and you were not the
|
|
root user when you executed the above command then that part of
|
|
the installation probably failed. In that case you should become
|
|
the root user and then do
|
|
<screen>
|
|
<userinput>gmake -C src/interfaces/perl5 install</userinput>
|
|
<userinput>gmake -C src/interfaces/python install</userinput>
|
|
</screen>
|
|
If you do not have superuser
|
|
access you are on your own: you can still take the required files
|
|
and place them in other directories where Perl or Python can find
|
|
them, but how to do that is left as an exercise.
|
|
</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>
|
|
|
|
<para>
|
|
To undo the installation use the command <command>gmake
|
|
uninstall</>. However, this will not remove any created directories.
|
|
</para>
|
|
</step>
|
|
</procedure>
|
|
|
|
<para>
|
|
After the installation you can make room by removing the built
|
|
files from the source tree with the <command>gmake clean</>
|
|
command. This will preserve the files made by the configure
|
|
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>
|
|
|
|
<para>
|
|
If you perform a build and then discover that your configure options
|
|
were wrong, or if you change anything that configure investigates
|
|
(for example, you install GNU <application>Readline</>), 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 libraries</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 Linux systems the following is the preferred method, but you
|
|
must have root access. Edit the file <filename>/etc/ld.so.conf</>
|
|
to add a line
|
|
<programlisting>
|
|
<filename>/usr/local/pgsql/lib</>
|
|
</programlisting>
|
|
Then run command <command>/sbin/ldconfig</>.
|
|
</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 need to
|
|
add <filename>/usr/local/pgsql/bin</> (or whatever you set
|
|
<option><literal>--bindir</></> to in <xref linkend="configure">)
|
|
into your <envar>PATH</>. 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
|
|
</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>
|
|
<seealso>man pages</seealso>
|
|
</indexterm>
|
|
To enable your system to find the <application>man</>
|
|
documentation, you need to add a line like the following to a
|
|
shell start-up file:
|
|
<programlisting>
|
|
MANPATH=/usr/local/pgsql/man:$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 <citetitle>Administrator's Guide</>
|
|
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 <citetitle>Tutorial</> 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 the <citetitle>Administrator's Guide</citetitle>,
|
|
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 <citetitle>Administrator's
|
|
Guide</citetitle>.
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
Run the regression tests against the installed server (using the
|
|
sequential test method). If you didn't run the tests before
|
|
installation, you should definitely do it now. This is also
|
|
explained in the <citetitle>Administrator's Guide</citetitle>.
|
|
</para>
|
|
</listitem>
|
|
|
|
</itemizedlist>
|
|
</para>
|
|
|
|
<!-- do we still ship this? -->
|
|
<!--
|
|
<para>
|
|
The documentation is also available in Postscript format. If you
|
|
have a Postscript printer, or have your machine already set up to
|
|
accept Postscript files using a print filter, then to print, for
|
|
example the <citetitle>User's Guide</> simply type
|
|
<programlisting>
|
|
cd /usr/local/pgsql/doc
|
|
gunzip -c user.ps.gz | lpr
|
|
</programlisting>
|
|
Here is how you might do it if you have <productname>Ghostscript</>
|
|
installed on your system and are writing to a Laserjet printer.
|
|
<programlisting>
|
|
gunzip -c user.ps.gz \
|
|
| gs -sDEVICE=laserjet -r300 -q -dNOPAUSE -sOutputFile=- \
|
|
| lpr
|
|
</programlisting>
|
|
Printer setups can vary wildly from system to system. If in doubt,
|
|
consult your manuals or your local expert.
|
|
</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.2</entry>
|
|
<entry>2001-12-19,
|
|
Andreas Zeugswetter (<email>ZeugswetterA@spardat.at</email>),
|
|
Tatsuo Ishii (<email>t-ishii@sra.co.jp</email>)</entry>
|
|
<entry>see also <filename>doc/FAQ_AIX</filename></entry>
|
|
</row>
|
|
<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>5.0.4</entry>
|
|
</row>
|
|
<row>
|
|
<entry><systemitem class="osname">BSD/OS</></entry>
|
|
<entry><systemitem>x86</></entry>
|
|
<entry>7.2</entry>
|
|
<entry>2001-11-27,
|
|
Bruce Momjian (<email>pgman@candle.pha.pa.us</email>)</entry>
|
|
<entry>4.2</entry>
|
|
</row>
|
|
<row>
|
|
<entry><systemitem class="osname">FreeBSD</></entry>
|
|
<entry><systemitem>Alpha</></entry>
|
|
<entry>7.2</entry>
|
|
<entry>2001-12-18,
|
|
Chris Kings-Lynne (<email>chriskl@familyhealth.com.au</email>)</entry>
|
|
<entry></entry>
|
|
</row>
|
|
<row>
|
|
<entry><systemitem class="osname">FreeBSD</></entry>
|
|
<entry><systemitem>x86</></entry>
|
|
<entry>7.2</entry>
|
|
<entry>2001-11-14,
|
|
Chris Kings-Lynne (<email>chriskl@familyhealth.com.au</email>)</entry>
|
|
<entry></entry>
|
|
</row>
|
|
<row>
|
|
<entry><systemitem class="osname">HP-UX</></entry>
|
|
<entry><systemitem>PA-RISC</></entry>
|
|
<entry>7.2</entry>
|
|
<entry>2001-11-29,
|
|
Joseph Conway (<email>Joseph.Conway@home.com</email>),
|
|
Tom Lane (<email>tgl@sss.pgh.pa.us</email>)</entry>
|
|
<entry>11.00 and 10.20; see also <filename>doc/FAQ_HPUX</filename></entry>
|
|
</row>
|
|
<row>
|
|
<entry><systemitem class="osname">IRIX</></entry>
|
|
<entry><systemitem>MIPS</></entry>
|
|
<entry>7.2</entry>
|
|
<entry>2001-11-28,
|
|
Luis Amigo (<email>lamigo@atc.unican.es</email>)</entry>
|
|
<entry>6.5.13, MIPSPro 7.30</entry>
|
|
</row>
|
|
<row>
|
|
<entry><systemitem class="osname">Linux</></entry>
|
|
<entry><systemitem>Alpha</></entry>
|
|
<entry>7.2</entry>
|
|
<entry>2001-11-16,
|
|
Tom Lane (<email>tgl@sss.pgh.pa.us</email>)</entry>
|
|
<entry>2.2.18; tested at SourceForge</entry>
|
|
</row>
|
|
<row>
|
|
<entry><systemitem class="osname">Linux</></entry>
|
|
<entry><systemitem>armv4l</></entry>
|
|
<entry>7.2</entry>
|
|
<entry>2001-12-10,
|
|
Mark Knox (<email>segfault@hardline.org</email>)</entry>
|
|
<entry>2.2.x</entry>
|
|
</row>
|
|
<row>
|
|
<entry><systemitem class="osname">Linux</></entry>
|
|
<entry><systemitem>MIPS</></entry>
|
|
<entry>7.2</entry>
|
|
<entry>2001-11-15,
|
|
Hisao Shibuya (<email>shibuya@alpha.or.jp</>)</entry>
|
|
<entry>2.0.x; <productname>Cobalt Qube2</></entry>
|
|
</row>
|
|
<row>
|
|
<entry><systemitem class="osname">Linux</></entry>
|
|
<entry><systemitem>PlayStation 2</></entry>
|
|
<entry>7.2</entry>
|
|
<entry>2001-12-12,
|
|
Permaine Cheung <email>pcheung@redhat.com</email>)</entry>
|
|
<entry>#undef HAS_TEST_AND_SET, slock_t</entry>
|
|
</row>
|
|
<row>
|
|
<entry><systemitem class="osname">Linux</></entry>
|
|
<entry><systemitem>PPC74xx</></entry>
|
|
<entry>7.2</entry>
|
|
<entry>2001-11-16,
|
|
Tom Lane (<email>tgl@sss.pgh.pa.us</email>)</entry>
|
|
<entry>2.2.18; Apple G3</entry>
|
|
</row>
|
|
<row>
|
|
<entry><systemitem class="osname">Linux</></entry>
|
|
<entry><systemitem>S/390</></entry>
|
|
<entry>7.2</entry>
|
|
<entry>2001-12-12,
|
|
Permaine Cheung <email>pcheung@redhat.com</email>)</entry>
|
|
<entry></entry>
|
|
</row>
|
|
<row>
|
|
<entry><systemitem class="osname">Linux</></entry>
|
|
<entry><systemitem>Sparc</></entry>
|
|
<entry>7.2</entry>
|
|
<entry>2001-11-28,
|
|
Doug McNaught (<email>doug@wireboard.com</email>)</entry>
|
|
<entry>2.2.19</entry>
|
|
</row>
|
|
<row>
|
|
<entry><systemitem class="osname">Linux</></entry>
|
|
<entry><systemitem>x86</></entry>
|
|
<entry>7.2</entry>
|
|
<entry>2001-11-15,
|
|
Thomas Lockhart (<email>lockhart@fourpalms.org</email>)</entry>
|
|
<entry>2.0.x, 2.2.x, 2.4.x</entry>
|
|
</row>
|
|
<row>
|
|
<entry><systemitem class="osname">MacOS X</></entry>
|
|
<entry><systemitem>PPC</></entry>
|
|
<entry>7.2</entry>
|
|
<entry>2001-11-28,
|
|
Gavin Sherry (<email>swm@linuxworld.com.au</email>)</entry>
|
|
<entry>10.1.x</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>arm32</></entry>
|
|
<entry>7.1</entry>
|
|
<entry>2001-03-21,
|
|
Patrick Welche (<email>prlw1@cam.ac.uk</email>)</entry>
|
|
<entry>1.5E</entry>
|
|
</row>
|
|
<row>
|
|
<entry><systemitem class="osname">NetBSD</></entry>
|
|
<entry><systemitem>m68k</></entry>
|
|
<entry>7.0</entry>
|
|
<entry>2000-04-10,
|
|
Henry B. Hotz (<email>hotz@jpl.nasa.gov</email>)</entry>
|
|
<entry>Mac 8xx</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>Sparc</></entry>
|
|
<entry>7.2</entry>
|
|
<entry>2001-12-03,
|
|
Matthew Green (<email>mrg@eterna.com.au</email>)</entry>
|
|
<entry>32- and 64-bit builds</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">NetBSD</></entry>
|
|
<entry><systemitem>x86</></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">OpenBSD</></entry>
|
|
<entry><systemitem>Sparc</></entry>
|
|
<entry>7.2</entry>
|
|
<entry>2001-11-27,
|
|
Brandon Palmer (<email>bpalmer@crimelabs.net</email>)</entry>
|
|
<entry>3.0</entry>
|
|
</row>
|
|
<row>
|
|
<entry><systemitem class="osname">OpenBSD</></entry>
|
|
<entry><systemitem>x86</></entry>
|
|
<entry>7.2</entry>
|
|
<entry>2001-11-26,
|
|
Brandon Palmer (<email>bpalmer@crimelabs.net</email>)</entry>
|
|
<entry>3.0</entry>
|
|
</row>
|
|
<row>
|
|
<entry><systemitem class="osname">Open UNIX</></entry>
|
|
<entry><systemitem>x86</></entry>
|
|
<entry>7.2</entry>
|
|
<entry>2001-11-28,
|
|
OU-8 Larry Rosenman (<email>ler@lerctr.org</email>),
|
|
UW-7 Olivier Prenant (<email>ohp@pyrenet.fr</email>)</entry>
|
|
<entry>see also <filename>doc/FAQ_SCO</filename></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>4.25; see also <filename>doc/FAQ_QNX4</filename></entry>
|
|
</row>
|
|
<row>
|
|
<entry><systemitem class="osname">Solaris</></entry>
|
|
<entry><systemitem>Sparc</></entry>
|
|
<entry>7.2</entry>
|
|
<entry>2001-11-12,
|
|
Andrew Sullivan (<email>andrew@libertyrms.com</email>)</entry>
|
|
<entry>2.6-8; see also <filename>doc/FAQ_Solaris</filename></entry>
|
|
</row>
|
|
<row>
|
|
<entry><systemitem class="osname">Solaris</></entry>
|
|
<entry><systemitem>x86</></entry>
|
|
<entry>7.2</entry>
|
|
<entry>2001-11-28,
|
|
Martin Renters (<email>martin@datafax.com</email>)</entry>
|
|
<entry>2.8; see also <filename>doc/FAQ_Solaris</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>
|
|
<row>
|
|
<entry><systemitem class="osname">Tru64 UNIX</></entry>
|
|
<entry><systemitem>Alpha</></entry>
|
|
<entry>7.2</entry>
|
|
<entry>2001-11-26,
|
|
Alessio Bragadini (<email>alessio@albourne.com</email>),
|
|
Bernd Tegge (<email>tegge@repas-aeg.de</email>)</entry>
|
|
<entry>5.0; 4.0g with cc and gcc</entry>
|
|
</row>
|
|
<row>
|
|
<entry><systemitem class="osname">Windows</></entry>
|
|
<entry><systemitem>x86</></entry>
|
|
<entry>7.2</entry>
|
|
<entry>2001-12-13,
|
|
Dave Page (<email>dpage@vale-housing.co.uk</email>),
|
|
Jason Tishler (<email>jason@tishler.net</email>)</entry>
|
|
<entry>with <application>Cygwin</application>; see <filename>doc/FAQ_MSWIN</filename></entry>
|
|
</row>
|
|
<row>
|
|
<entry><systemitem class="osname">Windows</></entry>
|
|
<entry><systemitem>x86</></entry>
|
|
<entry>7.2</entry>
|
|
<entry>2001-12-10,
|
|
Dave Page (<email>dpage@vale-housing.co.uk</email>)</entry>
|
|
<entry>
|
|
native is client-side only;
|
|
<![%standalone-include[see Administrator's Guide]]>
|
|
<![%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">DG/UX 5.4R4.11</></entry>
|
|
<entry><systemitem>m88k</></entry>
|
|
<entry>6.3</entry>
|
|
<entry>1998-03-01, Brian E Gallew (<email>geek+@cmu.edu</email>)</entry>
|
|
<entry>no recent reports</entry>
|
|
</row>
|
|
<row>
|
|
<entry><systemitem class="osname">MkLinux DR1</></entry>
|
|
<entry><systemitem>PPC750</></entry>
|
|
<entry>7.0</entry>
|
|
<entry>2001-04-03, Tatsuo Ishii (<email>t-ishii@sra.co.jp</email>)</entry>
|
|
<entry>7.1 needs OS update?</entry>
|
|
</row>
|
|
<row>
|
|
<entry><systemitem class="osname">NeXTSTEP</></entry>
|
|
<entry><systemitem>x86</></entry>
|
|
<entry>6.x</entry>
|
|
<entry>1998-03-01, David Wetzel (<email>dave@turbocat.de</email>)</entry>
|
|
<entry>bit rot suspected</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 5</></entry>
|
|
<entry><systemitem>x86</></entry>
|
|
<entry>6.5</entry>
|
|
<entry>1999-05-25, Andrew Merrill (<email>andrew@compclass.com</>)</entry>
|
|
<entry>&version; should work, but no reports; see also <filename>doc/FAQ_SCO</filename></entry>
|
|
</row>
|
|
<row>
|
|
<entry><systemitem class="osname">System V R4</></entry>
|
|
<entry><systemitem>m88k</></entry>
|
|
<entry>6.2.1</entry>
|
|
<entry>1998-03-01, Doug Winterburn (<email>dlw@seavme.xroads.com</email>)</entry>
|
|
<entry>needs new <acronym>TAS</acronym> spinlock code</entry>
|
|
</row>
|
|
<row>
|
|
<entry><systemitem class="osname">System V R4</></entry>
|
|
<entry><systemitem>MIPS</></entry>
|
|
<entry>6.4</entry>
|
|
<entry>1998-10-28, Frank Ridderbusch (<email>ridderbusch.pad@sni.de</email>)</entry>
|
|
<entry>no recent reports</entry>
|
|
</row>
|
|
<row>
|
|
<entry><systemitem class="osname">Ultrix</></entry>
|
|
<entry><systemitem>MIPS</></entry>
|
|
<entry>7.1</entry>
|
|
<entry>2001-03-26</entry>
|
|
<entry><acronym>TAS</acronym> spinlock code not detected</entry>
|
|
</row>
|
|
<row>
|
|
<entry><systemitem class="osname">Ultrix</></entry>
|
|
<entry><systemitem>VAX</></entry>
|
|
<entry>6.x</entry>
|
|
<entry>1998-03-01</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:
|
|
-->
|