PostgreSQL>]]>
Installation Instructionsinstallation
This
describes the installation of
PostgreSQL from the source code
distribution. (If you are installing a pre-packaged distribution,
such as an RPM or Debian package, ignore this
and read the packager's instructions instead.)
Short Version
./configure
gmake
su
gmake install
adduser postgres
mkdir /usr/local/pgsql/data
chown postgres /usr/local/pgsql/data
su - postgres
/usr/local/pgsql/bin/initdb -D /usr/local/pgsql/data
/usr/local/pgsql/bin/postmaster -D /usr/local/pgsql/data >logfile 2>&1 &
/usr/local/pgsql/bin/createdb test
/usr/local/pgsql/bin/psql test
The long version is the rest of this
Requirements
In general, a modern Unix-compatible platform should be able to run
PostgreSQL>.
The platforms that had received specific testing at the
time of release are listed in
below. In the doc> subdirectory of the distribution
there are several platform-specific FAQ> documents you
might wish to consult if you are having trouble.
The following software packages are required for building
PostgreSQL>:
make
GNU> make> is required; other
make> programs will not> work.
GNU> make> is often installed under
the name gmake; this document will always
refer to it by that name. (On some systems
GNU make> is the default tool with the name
make>.) To test for GNU
make enter
gmake --version
It is recommended to use version 3.76.1 or later.
You need an ISO>/ANSI> C compiler. Recent
versions of GCC> are recommendable, but
PostgreSQL> is known to build with a wide variety
of compilers from different vendors.
gzip> is needed to unpack the distribution in the
first place.
readline
The GNU> Readline> library (for
comfortable line editing and command history retrieval) will be
used by default. If you don't want to use it then you must
specify the option for
configure>. (On NetBSD,
the libedit library is
Readline-compatible and is used if
libreadline is not found.) If you are using
a package-based Linux distribution, be aware that you need both
the readline> and readline-devel> packages,
if those are separate in your distribution.
installationon Windows
Additional software is needed to build
PostgreSQL on Windows>.
You can build PostgreSQL for
NT>-based versions of Windows>
(like Windows XP and 2003) using MinGW;
see doc/FAQ_MINGW> for details. You can also build
PostgreSQL using
Cygwin; see doc/FAQ_CYGWIN>.
A Cygwin-based build will work on older
versions of Windows>, but if you have a choice,
we recommend the MinGW approach.
While these are the only tool sets recommended for a complete build,
it is possible to build just the C client library
(libpq) and the interactive terminal
(psql) using other Windows>
tool sets. For details of that see
]]>.
The following packages are optional. They are not required in the
default configuration, but they are needed when certain build
options are enabled, as explained below.
To build the server programming language
PL/Perl you need a full
Perl installation, including the
libperl library and the header files.
Since PL/Perl will be a shared
library, the libperllibperl library must be a shared library
also on most platforms. This appears to be the default in
recent Perl versions, but it was not
in earlier versions, and in any case it is the choice of whomever
installed Perl at your site.
If you don't have the shared library but you need one, a message
like this will appear during the build to point out this fact:
*** Cannot build PL/Perl because libperl is not a shared library.
*** You might have to rebuild your Perl installation. Refer to
*** the documentation for details.
(If you don't follow the on-screen output you will merely notice
that the PL/Perl library object,
plperl.so or similar, will not be
installed.) If you see this, you will have to rebuild and
install Perl manually to be able to
build PL/Perl. During the
configuration process for Perl,
request a shared library.
To build the PL/Python> server programming
language, you need a Python
installation with the header files and the distutils module.
The distutils module is included by default with
Python 1.6 and later; users of
earlier versions of Python will need
to install it.
Since PL/Python will be a shared
library, the libpythonlibpython library must be a shared library
also on most platforms. This is not the case in a default
Python installation. If after
building and installing you have a file called
plpython.so (possibly a different
extension), then everything went well. Otherwise you should
have seen a notice like this flying by:
*** Cannot build PL/Python because libpython is not a shared library.
*** You might have to rebuild your Python installation. Refer to
*** the documentation for details.
That means you have to rebuild (part of) your
Python installation to supply this
shared library.
If you have problems, run Python> 2.3 or later's
configure using the --enable-shared> flag. On some
operating systems you don't have to build a shared library, but
you will have to convince the PostgreSQL> build
system of this. Consult the Makefile in
the src/pl/plpython directory for details.
If you want to build the PL/Tcl
procedural language, you of course need a Tcl installation.
To enable Native Language Support (NLS), that
is, the ability to display a program's messages in a language
other than English, you need an implementation of the
Gettext> API. Some operating
systems have this built-in (e.g., Linux>, NetBSD>,
Solaris>), for other systems you
can download an add-on package from here: .
If you are using the Gettext> implementation in
the GNU C library then you will additionally
need the GNU Gettext package for some
utility programs. For any of the other implementations you will
not need it.
Kerberos>, OpenSSL>, and/or
PAM>, if you want to support authentication or
encryption using these services.
If you are building from a CVS tree instead of
using a released source package, or if you want to do development,
you also need the following packages:
flexbisonyacc
GNU Flex> and Bison>
are needed to build a CVS checkout or if you changed the actual
scanner and parser definition files. If you need them, be sure
to get Flex> 2.5.4 or later and
Bison> 1.875 or later. Other yacc>
programs can sometimes be used, but doing so requires extra
effort and is not recommended. Other lex>
programs will definitely not work.
If you need to get a GNU package, you can find
it at your local GNU mirror site (see >
for a list) or at .
Also check that you have sufficient disk space. You will need about
65 MB for the source tree during compilation and about 15 MB for
the installation directory. An empty database cluster takes about
25 MB, databases take about five times the amount of space that a
flat text file with the same data would take. If you are going to
run the regression tests you will temporarily need up to an extra
90 MB. Use the df command to check free disk
space.
Getting The Source
The PostgreSQL> &version; sources can be obtained by
anonymous FTP from .
Use a mirror if possible. After you have obtained the file, unpack it:
gunzip postgresql-&version;.tar.gztar xf postgresql-&version;.tar
This will create a directory
postgresql-&version; under the current directory
with the PostgreSQL> sources.
Change into that directory for the rest
of the installation procedure.
]]>
If You Are Upgradingupgrading
The internal data storage format changes with new releases of
PostgreSQL>. Therefore, if you are upgrading an
existing installation that does not have a version number
&majorversion;.x, you must back up and restore your
data as shown here. These instructions assume that your existing
installation is under the /usr/local/pgsql> directory,
and that the data area is in /usr/local/pgsql/data>.
Substitute your paths appropriately.
Make sure that your database is not updated during or after the
backup. This does not affect the integrity of the backup, but the
changed data would of course not be included. If necessary, edit
the permissions in the file
/usr/local/pgsql/data/pg_hba.conf> (or equivalent) to
disallow access from everyone except you.
pg_dumpalluse during upgrade
To back up your database installation, type:
pg_dumpall > outputfile>
If you need to preserve OIDs (such as when using them as
foreign keys), then use the option when running
pg_dumpall>.
pg_dumpall does not
save large objects. Check
]]>
if you need to do this.
To make the backup, you can use the pg_dumpall
command from the version you are currently running. For best
results, however, try to use the pg_dumpall
command from PostgreSQL &version;,
since this version contains bug fixes and improvements over older
versions. While this advice might seem idiosyncratic since you
haven't installed the new version yet, it is advisable to follow
it if you plan to install the new version in parallel with the
old version. In that case you can complete the installation
normally and transfer the data later. This will also decrease
the downtime.
If you are installing the new version at the same location as the
old one then shut down the old server, at the latest before you
install the new files:
pg_ctl stop>
On systems that have PostgreSQL> started at boot time,
there is probably a start-up file that will accomplish the same thing. For
example, on a Red Hat Linux> system one
might find that
/etc/rc.d/init.d/postgresql stop
works.
Very old versions might not have pg_ctl>. If you
can't find it or it doesn't work, find out the process ID of the
old server, for example by typing
ps ax | grep postmaster
and signal it to stop this way:
kill -INT processID>
If you are installing in the same place as the old version then
it is also a good idea to move the old installation out of the
way, in case you have trouble and need to revert to it.
Use a command like this:
mv /usr/local/pgsql /usr/local/pgsql.old>
After you have installed PostgreSQL> &version;, create a new database
directory and start the new server. Remember that you must execute
these commands while logged in to the special database user account
(which you already have if you are upgrading).
/usr/local/pgsql/bin/initdb -D /usr/local/pgsql/data>
/usr/local/pgsql/bin/postmaster -D /usr/local/pgsql/data>
Finally, restore your data with
/usr/local/pgsql/bin/psql -d template1 -f outputfile>
using the new> psql>.
Further discussion appears in
,]]>
which you are encouraged to read in any case.
Installation ProcedureConfiguration>
configure
The first step of the installation procedure is to configure the
source tree for your system and choose the options you would like.
This is done by running the configure> script. For a
default installation simply enter
./configure
This script will run a number of tests to guess values for various
system dependent variables and detect some quirks of your
operating system, and finally will create several files in the
build tree to record what it found. (You can also run
configure in a directory outside the source
tree if you want to keep the build directory separate.)
The default configuration will build the server and utilities, as
well as all client applications and interfaces that require only a
C compiler. All files will be installed under
/usr/local/pgsql> by default.
You can customize the build and installation process by supplying one
or more of the following command line options to
configure:
Install all files under the directory PREFIX>
instead of /usr/local/pgsql. The actual
files will be installed into various subdirectories; no files
will ever be installed directly into the
PREFIX> directory.
If you have special needs, you can also customize the
individual subdirectories with the following options. However,
if you leave these with their defaults, the installation will be
relocatable, meaning you can move the directory after
installation. (The man> and doc>
locations are not affected by this.)
For relocatable installs, you might want to use
configure's --disable-rpath>
option. Also, you will need to tell the operating system how
to find the shared libraries.
You can install architecture-dependent files under a
different prefix, EXEC-PREFIX>, than what
PREFIX> was set to. This can be useful to
share architecture-independent files between hosts. If you
omit this, then EXEC-PREFIX> is set equal to
PREFIX> and both architecture-dependent and
independent files will be installed under the same tree,
which is probably what you want.
Specifies the directory for executable programs. The default
is EXEC-PREFIX>/bin>, which
normally means /usr/local/pgsql/bin>.
Sets the directory for read-only data files used by the
installed programs. The default is
PREFIX>/share>. Note that this has
nothing to do with where your database files will be placed.
The directory for various configuration files,
PREFIX>/etc> by default.
The location to install libraries and dynamically loadable
modules. The default is
EXEC-PREFIX>/lib>.
The directory for installing C and C++ header files. The
default is PREFIX>/include>.
The man pages that come with PostgreSQL> will be installed under
this directory, in their respective
manx>> subdirectories.
The default is PREFIX>/man>.
Documentation files, except man> pages, will be
installed into this directory. The default is
PREFIX>/doc>. If the option
is specified, the
documentation will not be installed by make
install. This is intended for packaging scripts
that have special methods for installing documentation.
Care has been taken to make it possible to install
PostgreSQL> into shared installation locations
(such as /usr/local/include) without
interfering with the namespace of the rest of the system. First,
the string /postgresql is
automatically appended to datadir,
sysconfdir, and docdir,
unless the fully expanded directory name already contains the
string postgres> or
pgsql>. For example, if you choose
/usr/local as prefix, the documentation will
be installed in /usr/local/doc/postgresql,
but if the prefix is /opt/postgres, then it
will be in /opt/postgres/doc. The public C
header files of the client interfaces are installed into
includedir and are namespace-clean. The
internal header files and the server header files are installed
into private directories under includedir. See
the documentation of each interface for information about how to
get at the its header files. Finally, a private subdirectory will
also be created, if appropriate, under libdir
for dynamically loadable modules.
DIRECTORIES> is a colon-separated list of
directories that will be added to the list the compiler
searches for header files. If you have optional packages
(such as GNU Readline>) installed in a non-standard
location,
you have to use this option and probably also the corresponding
Example: --with-includes=/opt/gnu/include:/usr/sup/include>.
DIRECTORIES> is a colon-separated list of
directories to search for libraries. You will probably have
to use this option (and the corresponding
Example: --with-libraries=/opt/gnu/lib:/usr/sup/lib>.
Enables Native Language Support (NLS),
that is, the ability to display a program's messages in a
language other than English.
LANGUAGES is a space-separated
list of codes of the languages that you want supported, for
example --enable-nls='de fr'>. (The intersection
between your list and the set of actually provided
translations will be computed automatically.) If you do not
specify a list, then all available translations are
installed.
To use this option, you will need an implementation of the
Gettext> API; see above.
Set NUMBER> as the default port number for
server and clients. The default is 5432. The port can always
be changed later on, but if you specify it here then both
server and clients will have the same default compiled in,
which can be very convenient. Usually the only good reason
to select a non-default value is if you intend to run multiple
PostgreSQL> servers on the same machine.
Build the PL/Perl> server-side language.
Build the PL/Python> server-side language.
Build the PL/Tcl> server-side language.
Tcl installs the file tclConfig.sh, 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.
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., /usr/include>,
/usr/lib>), so you must use the options
The name of the Kerberos service principal.
postgres is the default. There's probably no
reason to change this.
OpenSSLSSL
Build with support for SSL> (encrypted)
connections. This requires the OpenSSL>
package to be installed. configure> will check
for the required header files and libraries to make sure that
your OpenSSL> installation is sufficient
before proceeding.
Build with PAM>PAM>>
(Pluggable Authentication Modules) support.
Prevents use of the Readline> library. This disables
command-line editing and history in
psql, so it is not recommended.
Build with Rendezvous support. This requires Rendezvous support
in your operating system. Recommended on Mac OS X.
Allow the build to succeed even if 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 PostgreSQL> on
your platform, please report the problem to the
PostgreSQL> developers.
Make the client libraries thread-safe. This allows
concurrent threads in libpq and
ECPG programs to safely control
their private connection handles. This option requires adequate
threading support in your operating system.
zlib
Prevents use of the Zlib> library. This disables
support for compressed archives in pg_dump
and pg_restore.
This option is only intended for those rare systems where this
library is not available.
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.
Enables assertion> checks in the server, which test for
many can't happen> conditions. This is invaluable for
code development purposes, but the tests slow things down a little.
Also, having the tests turned on won't necessarily enhance the
stability of your server! The assertion checks are not categorized
for severity, and so what might be a relatively harmless bug will
still lead to server restarts if it triggers an assertion
failure. Currently, this option is not recommended for
production use, but you should have it on for development work
or when running a beta version.
Enables automatic dependency tracking. With this option, the
makefiles are set up so that all affected object files will
be rebuilt when any header file is changed. This is useful
if you are doing development work, but is just wasted overhead
if you intend only to compile once and install. At present,
this option will work only if you use GCC.
If you prefer a C compiler different from the one
configure picks, you can set the
environment variable CC> to the program of your choice.
By default, configure will pick
gcc if available, else the platform's
default (usually cc>). Similarly, you can override the
default compiler flags if needed with the CFLAGS variable.
You can specify environment variables on the
configure command line, for example:
./configure CC=/opt/bin/gcc CFLAGS='-O2 -pipe'>
Build
To start the build, type
gmake
(Remember to use GNU> make>.) The build
may take anywhere from 5 minutes to half an hour depending on your
hardware. The last line displayed should be
All of PostgreSQL is successfully made. Ready to install.
Regression Testsregression test
If you want to test the newly built server before you install it,
you can run the regression tests at this point. The regression
tests are a test suite to verify that PostgreSQL>
runs on your machine in the way the developers expected it
to. Type
gmake check
(This won't work as root; do it as an unprivileged user.)
src/test/regress/README> and the
documentation contain]]>
contains]]>
detailed information about interpreting the test results. You can
repeat this test at any later time by issuing the same command.
Installing The Files
If you are upgrading an existing system and are going to install
the new files over the old ones, be sure to back up
your data and shut down the old server before proceeding, as explained in
above.
To install PostgreSQL> enter
gmake install
This will install files into the directories that were specified
in . Make sure that you have appropriate
permissions to write into that area. Normally you need to do this
step as root. Alternatively, you could create the target
directories in advance and arrange for appropriate permissions to
be granted.
You can use gmake install-strip instead of
gmake install to strip the executable files and
libraries as they are installed. This will save some space. If
you built with debugging support, stripping will effectively
remove the debugging support, so it should only be done if
debugging is no longer needed. install-strip
tries to do a reasonable job saving space, but it does not have
perfect knowledge of how to strip every unneeded byte from an
executable file, so if you want to save all the disk space you
possibly can, you will have to do manual work.
The standard installation provides all the header files needed for client
application development as well as for server-side program
development, such as custom functions or data types written in C.
(Prior to PostgreSQL> 8.0, a separate gmake
install-all-headers> command was needed for the latter, but this
step has been folded into the standard install.)
Client-only installation:
If you want to install only the client applications and
interface libraries, then you can use these commands:
gmake -C src/bin install>
gmake -C src/include install>
gmake -C src/interfaces install>
gmake -C doc install>
Registering eventlog> on Windows>:
To register a Windows> eventlog>
library with the operating system, issue this command after installation:
regsvr32 pgsql_library_directory>/pgevent.dll>
This creates registry entries used by the event viewer.
Uninstallation:
To undo the installation use the command gmake
uninstall>. However, this will not remove any created directories.
Cleaning:
After the installation you can make room by removing the built
files from the source tree with the command gmake
clean>. This will preserve the files made by the configure
program, so that you can rebuild everything with gmake>
later on. To reset the source tree to the state in which it was
distributed, use gmake distclean>. If you are going to
build for several platforms within the same source tree you must do
this and re-configure for each build. (Alternatively, use
a separate build tree for each platform, so that the source tree
remains unmodified.)
If you perform a build and then discover that your configure>
options were wrong, or if you change anything that configure>
investigates (for example, software upgrades), then it's a good
idea to do gmake distclean> before reconfiguring and
rebuilding. Without this, your changes in configuration choices
may not propagate everywhere they need to.
Post-Installation SetupShared Librariesshared library
On some systems that have shared libraries (which most systems do)
you need to tell your system how to find the newly installed
shared libraries. The systems on which this is
not necessary include BSD/OS>, FreeBSD>,
HP-UX>, IRIX>, Linux>,
NetBSD>, OpenBSD>, Tru64
UNIX> (formerly Digital UNIX>), and
Solaris>.
The method to set the shared library search path varies between
platforms, but the most widely usable method is to set the
environment variable LD_LIBRARY_PATH> like so: In Bourne
shells (sh>, ksh>, bash>, zsh>)
LD_LIBRARY_PATH=/usr/local/pgsql/lib
export LD_LIBRARY_PATH
or in csh> or tcsh>
setenv LD_LIBRARY_PATH /usr/local/pgsql/lib
Replace /usr/local/pgsql/lib> with whatever you set
On some systems it might be preferable to set the environment
variable LD_RUN_PATHbefore
building.
On Cygwin, put the library
directory in the PATH or move the
.dll files into the bin
directory.
If in doubt, refer to the manual pages of your system (perhaps
ld.so or rld). If you later
on get a message like
psql: error in loading shared libraries
libpq.so.2.1: cannot open shared object file: No such file or directory
then this step was necessary. Simply take care of it then.
ldconfig
If you are on BSD/OS>, Linux>, or SunOS 4>
and you have root access you can run
/sbin/ldconfig /usr/local/pgsql/lib
(or equivalent directory) after installation to enable the
run-time linker to find the shared libraries faster. Refer to the
manual page of ldconfig> for more information. On
FreeBSD>, NetBSD>, and OpenBSD> the command is
/sbin/ldconfig -m /usr/local/pgsql/lib
instead. Other systems are not known to have an equivalent
command.
Environment VariablesPATH
If you installed into /usr/local/pgsql> or some other
location that is not searched for programs by default, you should
add /usr/local/pgsql/bin> (or whatever you set
To do this, add the following to your shell start-up file, such as
~/.bash_profile> (or /etc/profile>, if you
want it to affect every user):
PATH=/usr/local/pgsql/bin:$PATH
export PATH
If you are using csh> or tcsh>, then use this command:
set path = ( /usr/local/pgsql/bin $path )
MANPATH
To enable your system to find the man>
documentation, you need to add lines like the following to a
shell start-up file unless you installed into a location that is
searched by default.
MANPATH=/usr/local/pgsql/man:$MANPATH
export MANPATH
The environment variables PGHOST> and PGPORT>
specify to client applications the host and port of the database
server, overriding the compiled-in defaults. If you are going to
run client applications remotely then it is convenient if every
user that plans to use the database sets PGHOST>. This
is not required, however: the settings can be communicated via command
line options to most client programs.
Getting Started
The following is a quick summary of how to get PostgreSQL> up and
running once installed. The main documentation contains more information.
Create a user account for the PostgreSQL>
server. This is the user the server will run as. For production
use you should create a separate, unprivileged account
(postgres> is commonly used). If you do not have root
access or just want to play around, your own user account is
enough, but running the server as root is a security risk and
will not work.
adduser postgres>
Create a database installation with the initdb>
command. To run initdb> you must be logged in to your
PostgreSQL> server account. It will not work as
root.
root# mkdir /usr/local/pgsql/data>
root# chown postgres /usr/local/pgsql/data>
root# su - postgres>
postgres$ /usr/local/pgsql/bin/initdb -D /usr/local/pgsql/data>
The
The previous step should have told you how to start up the
database server. Do so now. The command should look something
like
/usr/local/pgsql/bin/postmaster -D /usr/local/pgsql/data
This will start the server in the foreground. To put the server
in the background use something like
nohup /usr/local/pgsql/bin/postmaster -D /usr/local/pgsql/data \
</dev/null >>server.log 2>&1 </dev/null &
To stop a server running in the background you can type
kill `cat /usr/local/pgsql/data/postmaster.pid`
In order to allow TCP/IP connections (rather than only Unix
domain socket ones) you need to pass the
Create a database:
createdb testdb>
Then enter
psql testdb>
to connect to that database. At the prompt you can enter SQL
commands and start experimenting.
What Now?
The PostgreSQL> distribution contains a
comprehensive documentation set, which you should read sometime.
After installation, the documentation can be accessed by
pointing your browser to
/usr/local/pgsql/doc/html/index.html>, unless you
changed the installation directories.
The first few chapters of the main documentation are the Tutorial,
which should be your first reading if you are completely new to
SQL> databases. If you are familiar with database
concepts then you want to proceed with part on server
administration, which contains information about how to set up
the database server, database users, and authentication.
Usually, you will want to modify your computer so that it will
automatically start the database server whenever it boots. Some
suggestions for this are in the documentation.
Run the regression tests against the installed server (using
gmake installcheck). If you didn't run the
tests before installation, you should definitely do it now. This
is also explained in the documentation.
By default, PostgreSQL> is configured to run on
minimal hardware. This allows it to start up with almost any
hardware configuration. The default configuration is, however,
not designed for optimum performance. To achieve optimum
performance, several server parameters must be adjusted, the two
most common being shared_buffers and
work_mem.
Other parameters mentioned in the documentation also affect
performance.
]]>
Supported PlatformsPostgreSQL> has been verified by the developer
community to work on the platforms listed below. A supported
platform generally means that PostgreSQL> builds and
installs according to these instructions and that the regression
tests pass. Build farm entries refer to builds
reported by the PostgreSQL
Build Farm.
If you are having problems with the installation on a supported
platform, please write to pgsql-bugs@postgresql.org
or pgsql-ports@postgresql.org, not to the people
listed here.
OSProcessorVersionReportedRemarksAIX>PowerPC>8.0.0Travis P (twp@castle.fastmail.fm), 2004-12-12see also doc/FAQ_AIXAIX>RS6000>8.0.0Hans-Jürgen Schönig (hs@cybertec.at), 2004-12-06see also doc/FAQ_AIXBSD/OS>x86>8.0.0Bruce Momjian (pgman@candle.pha.pa.us), 2004-12-074.3.1Debian GNU/Linux>Alpha>7.4Noèl Köthe (noel@debian.org), 2003-10-25Debian GNU/Linux>AMD64>8.0.0Build farm panda, snapshot 2004-12-06 01:20:02sid, kernel 2.6Debian GNU/Linux>ARM>8.0.0Jim Buttafuoco (jim@contactbda.com), 2005-01-06Debian GNU/Linux>Itanium>7.4Noèl Köthe (noel@debian.org), 2003-10-25Debian GNU/Linux>m68k>8.0.0Noèl Köthe (noel@debian.org), 2004-12-09sidDebian GNU/Linux>MIPS>8.0.0Build farm lionfish, snapshot 2004-12-06 11:00:083.1 (sarge), kernel 2.4Debian GNU/Linux>PA-RISC>8.0.0Noèl Köthe (noel@debian.org), 2004-12-07sidDebian GNU/Linux>PowerPC>8.0.0Noèl Köthe (noel@debian.org), 2004-12-15sidDebian GNU/Linux>S/390>7.4Noèl Köthe (noel@debian.org), 2003-10-25Debian GNU/Linux>Sparc>8.0.0Noèl Köthe (noel@debian.org), 2004-12-09sid, 32-bitDebian GNU/Linux>x86>8.0.0Peter Eisentraut (peter_e@gmx.net), 2004-12-063.1 (sarge), kernel 2.6Fedora>AMD64>8.0.0John Gray (jgray@azuli.co.uk), 2004-12-12FC3Fedora>x86>8.0.0Build farm dog, snapshot 2004-12-06 02:06:01FC1FreeBSD>Alpha>7.4Peter Eisentraut (peter_e@gmx.net), 2003-10-254.8FreeBSD>x86>8.0.0Build farm cockatoo, snapshot 2004-12-06 14:10:01 (4.10);
Marc Fournier (scrappy@postgresql.org), 2004-12-07 (5.3)Gentoo Linux>x86>8.0.0Paul Bort (pbort@tmwsystems.com), 2004-12-07HP-UX>Itanium>8.0.0Tom Lane (tgl@sss.pgh.pa.us), 2005-01-0611.23, gcc> and cc>; see also doc/FAQ_HPUXHP-UX>PA-RISC>8.0.0Tom Lane (tgl@sss.pgh.pa.us), 2005-01-0610.20 and 11.11, gcc> and cc>; see also doc/FAQ_HPUXIRIX>MIPS>7.4Robert E. Bruccoleri (bruc@stone.congenomics.com), 2003-11-126.5.20, cc onlyMac OS X>PowerPC>8.0.0Andrew Rawnsley (ronz@ravensfield.com), 2004-12-0710.3.5Mandrakelinux>x86>8.0.0Build farm shrew, snapshot 2004-12-06 02:02:0110.0NetBSD>arm32>7.4Patrick Welche (prlw1@newn.cam.ac.uk), 2003-11-121.6ZE/acorn32NetBSD>m68k>8.0.0Rémi Zara (remi_zara@mac.com), 2004-12-142.0NetBSD>Sparc>7.4.1Peter Eisentraut (peter_e@gmx.net), 2003-11-261.6.1, 32-bitNetBSD>x86>8.0.0Build farm canary, snapshot 2004-12-06 03:30:001.6OpenBSD>Sparc64>8.0.0Build farm spoonbill, snapshot 2005-01-06 00:50:053.6OpenBSD>x86>8.0.0Build farm emu, snapshot 2004-12-06 11:35:033.6Red Hat Linux>AMD64>8.0.0Tom Lane (tgl@sss.pgh.pa.us), 2004-12-07RHEL 3ASRed Hat Linux>IA64>8.0.0Tom Lane (tgl@sss.pgh.pa.us), 2004-12-07RHEL 3ASRed Hat Linux>PowerPC>8.0.0Tom Lane (tgl@sss.pgh.pa.us), 2004-12-07RHEL 3ASRed Hat Linux>PowerPC 64>8.0.0Tom Lane (tgl@sss.pgh.pa.us), 2004-12-07RHEL 3ASRed Hat Linux>S/390>8.0.0Tom Lane (tgl@sss.pgh.pa.us), 2004-12-07RHEL 3ASRed Hat Linux>S/390x>8.0.0Tom Lane (tgl@sss.pgh.pa.us), 2004-12-07RHEL 3ASRed Hat Linux>x86>8.0.0Tom Lane (tgl@sss.pgh.pa.us), 2004-12-07RHEL 3ASSolaris>Sparc>8.0.0Kenneth Marshall (ktm@is.rice.edu), 2004-12-07Solaris 8; see also doc/FAQ_SolarisSolaris>x86>8.0.0Build farm kudu, snapshot 2004-12-10 02:30:04 (cc);
dragonfly, snapshot 2004-12-09 04:30:00 (gcc)Solaris 9; see also doc/FAQ_SolarisTru64 UNIX>Alpha>8.0.0Honda Shigehiro (fwif0083@mb.infoweb.ne.jp), 2005-01-075.0UnixWare>x86>8.0.0Peter Eisentraut (peter_e@gmx.net), 2004-12-14cc, 7.1.4; see also doc/FAQ_SCOWindows>x86>8.0.0Dave Page (dpage@vale-housing.co.uk), 2004-12-07XP Pro; see doc/FAQ_MINGWWindows with Cygwin>x86>8.0.0Build farm gibbon, snapshot 2004-12-11 01:33:01see doc/FAQ_CYGWINUnsupported Platforms:
The following platforms are either known not to work, or they used
to work in a previous release and we did not receive explicit
confirmation of a successful test with version &majorversion; at
the time this list was compiled. We include these here to let you
know that these platforms could> be supported if given
some attention.
OSProcessorVersionReportedRemarksBeOS>x86>7.22001-11-29,
Cyril Velter (cyril.velter@libertysurf.fr)needs updates to semaphore codeLinux>PlayStation 2>7.42003-11-02,
Peter Eisentraut (peter_e@gmx.net)
needs new config.guess,
NetBSD>Alpha>7.22001-11-20,
Thomas Thai (tom@minnesota.com)1.5WNetBSD>MIPS>7.2.12002-06-13,
Warwick Hunter (whunter@agile.tv)1.5.3NetBSD>PowerPC>7.22001-11-28,
Bill Studenmund (wrstuden@netbsd.org)1.5NetBSD>VAX>7.12001-03-30,
Tom I. Helbekkmo (tih@kpnQwest.no)1.5QNX 4 RTOS>x86>7.22001-12-10,
Bernd Tegge (tegge@repas-aeg.de)
needs updates to semaphore code;
see also doc/FAQ_QNX4QNX RTOS v6>x86>7.22001-11-20, Igor Kovalenko (Igor.Kovalenko@motorola.com)patches available in archives, but too late for 7.2SCO OpenServer>x86>7.3.12002-12-11,
Shibashish Satpathy (shib@postmark.net>)5.0.4, gcc>; see also doc/FAQ_SCOSunOS 4>Sparc>7.22001-12-04, Tatsuo Ishii (t-ishii@sra.co.jp)