+ PostgreSQL Installation Instructions
-PostgreSQL Installation Guide
-by The PostgreSQL Development Team
-
-PostgreSQL is © 1998-9 by the Postgres Global Development Group.
-Table of Contents
-
- Summary
- 1. Introduction
- 2. Ports
- Currently Supported Platforms
- Unsupported Platforms
- 3. Installation
- Requirements to Run Postgres
- Installation Procedure
- Playing with Postgres
- The Next Step
- Porting Notes
- 4. Configuration Options
- Parameters for Configuration (configure)
- Parameters for Building (make)
- Locale Support
- What are the Benefits?
- What are the Drawbacks?
- Kerberos Authentication
- Availability
- Installation
- Operation
- 5. Release Notes
- Release 6.5
- Migration to v6.5
- Multi-Version Concurrency Control
- Detailed Change List
-
-Summary
-
- Postgres, developed originally in the UC Berkeley
- Computer Science Department, pioneered many of the
- object-relational concepts now becoming available in
- some commercial databases. It provides SQL92/SQL3
- language support, transaction integrity, and type
- extensibility. PostgreSQL is a public-domain, open
- source descendant of this original Berkeley code.
-
-Chapter 1. Introduction
-
- This installation procedure makes some assumptions
- about the desired configuration and runtime
- environment for your system. This may be adequate for
- many installations, and is almost certainly adequate
- for a first installation. But you may want to do an
- initial installation up to the point of unpacking the
- source tree and installing documentation, and then
- print or browse the Administrator's Guide.
-
-Chapter 2. Ports
-
- This manual describes version 6.5 of Postgres. The
- Postgres developer community has compiled and tested
- Postgres on a number of platforms. Check the web site
- (http://www.postgresql.org/docs/admin/ports.htm) for
- the latest information.
-
-Currently Supported Platforms
-
- At the time of publication, the following platforms
- have been tested:
-
- Table 2-1. Supported Platforms
- OS Processor Version Reported Remarks
- AIX 4.3.2 RS6000 v6.5 1999-05-26 (Andreas Zeugswetter
- (mailto:Andreas.Zeugswetter@telecom.at))
- BSDI x86 v6.5 1999-05-25 (Bruce Momjian
- (mailto:maillist@candle.pha.pa.us)
- FreeBSD x86 v6.5 1999-05-25 (Tatsuo Ishii
- 2.2.x-4.0 (mailto:t-ishii@sra.co.jp),
- Marc Fournier
- (mailto:scrappy@hub.org))
- DGUX m88k v6.3 1998-03-01 v6.4 probably OK.
- 5.4R4.11 Needs new maintainer.
- (Brian E Gallew
- (mailto:geek+@cmu.edu))
- Digital Alpha v6.4 1998-10-29 Minor patchable problems
- Unix 4.0 (Pedro J. Lobo
- (mailto:pjlobo@euitt.upm.es))
- HPUX PA-RISC v6.4 1998-10-25 Both 9.0x and 10.20
- (Tom Lane (mailto:tgl@sss.pgh.pa.us),
- Stan Brown (mailto:stanb@awod.com))
- IRIX 6.5 MIPS v6.4 1998-12-29 IRIX 5.x is different
- (Mark Dalphin (mdalphin@amgen.com))
- linux Alpha v6.3.2 1998-04-16 Mostly successful. Needs
- 2.0.x work for v6.4.
- (Ryan Kirkpatrick
- (mailto:rkirkpat@nag.cs.colorado.edu))
- linux x86 v6.4 1998-10-27 (Thomas Lockhart
- 2.0.x/libc5 (mailto:lockhart@alumni.caltech.edu))
- linux x86 v6.4 1999-05-24 (Thomas Lockhart
- 2.0.x/glibc2 (mailto:lockhart@alumni.caltech.edu))
- linux MIPS v6.4 1998-12-16 Cobalt Qube (Tatsuo Ishii
- 2.0.x (mailto:t-ishii@sra.co.jp))
- linux Sparc v6.4 1998-10-25 (Tom Szybist
- 2.0.x (mailto:szybist@boxhill.com))
- linuxPPC PPC603e v6.4 1998-10-26 Powerbook 2400c
- 2.1.24 (Tatsuo Ishii
- (mailto:t-ishii@sra.co.jp))
- mklinux PPC750 v6.4 1998-09-16 PowerMac 7600
- DR3 (Tatsuo Ishii
- (mailto:t-ishii@sra.co.jp))
- NetBSD arm32 v6.5 1999-04-14 (Andrew McMurry
- (mailto:a.mcmurry1@physics.oxford.ac.uk))
- NetBSD/i3- x86 v6.4 1998-10-25 (Brook Milligan
- 86 1.3.2 (mailto:brook@trillium.NMSU.Edu))
- NetBSD m68k v6.4.2 1998-12-28 Mac SE/30 (Mr. Mutsuki
- Nakajima, Tatsuo Ishii
- (mailto:t-ishii@sra.co.jp))
- NetBSD- NS32532 v6.4 1998-10-27 small problems
- current in date/time math (Jon Buller
- (mailto:jonb@metronet.com))
- NetBSD/sp- Sparc v6.4 1998-10-27 (Tom I Helbekkmo
- arc 1.3H (mailto:tih@hamartun.priv.no))
- NetBSD 1.3 VAX v6.3 1998-03-01 (Tom I Helbekkmo
- (mailto:tih@hamartun.priv.no))
- SCO x86 v6.5 1999-05-25 (Andrew Merrill
- OpenServer 5 (mailto:andrew@compclass.com))
- SCO x86 v6.5 1999-05-25 (Andrew Merrill
- UnixWare 7 (mailto:andrew@compclass.com))
- Solaris x86 v6.4 1998-10-28 (Marc Fournier
- (mailto:scrappy@hub.org))
- Solaris Sparc v6.4 1998-10-28 (Tom Szybist
- 2.6-2.7 (mailto:szybist@boxhill.com),
- Frank Ridderbusch
- (mailto:ridderbusch.pad@sni.de))
- SunOS Sparc v6.3 1998-03-01 Patches submitted
- 4.1.4 (Tatsuo Ishii
- (mailto:t-ishii@sra.co.jp))
- SVR4 MIPS v6.4 1998-10-28 No 64-bit int compiler
- support (Frank Ridderbusch
- (mailto:ridderbusch.pad@sni.de))
- Windows x86 v6.4 1999-01-06 Client-side libraries
- or ODBC/JDBC. No server yet.
- (Magnus Hagander
- (mha@sollentuna.net)
- Windows NT x86 v6.5 1999-05-26 Working with the Cygwin
- library. (Daniel Horak
- (mailto:Dan.Horak@email.cz))
-
-
-
- Platforms listed for v6.3.x and v6.4.x should also
- work with v6.5, but we did not receive explicit
- confirmation of such at the time this list was
- compiled.
-
- Note: For Windows NT, the server-side port of
- Postgres has recently been accomplished. The
- Cygnus library is required to compile it.
-
-Unsupported Platforms
-
- There are a few platforms which have been attempted
- and which have been reported to not work with the
- standard distribution. Others listed here do not
- provide sufficient library support for an attempt.
-
- Table 2-2. Possibly Incompatible Platforms
- OS Processor Version Reported Remarks
- MacOS all v6.3 1998-03-01 Not library compatible;
- use ODBC/JDBC
- NextStep x86 v6.x 1998-03-01 Client-only support;
- v1.0.9 worked with patches
- (David Wetzel
- (mailto:dave@turbocat.de))
- SVR4 4.4 m88k v6.2.1 1998-03-01 Confirmed
- with patching;
- v6.4.x will need TAS
- spinlock code (Doug
- Winterburn
- (mailto:dlw@seavme.xroads.com))
- Ultrix MIPS,VAX? v6.x 1998-03-01 No recent reports;
- obsolete?
-
-
-Chapter 3. Installation
-
- Complete installation instructions for Postgres
- v6.5.
-
- Before installing Postgres, you may wish to visit
- www.postgresql.org (http://www.postgresql.org) for up
- to date information, patches, etc.
- These installation instructions assume:
- o Commands are Unix-compatible. See note below.
- o Defaults are used except where noted.
- o User postgres is the Postgres superuser.
- o The source path is /usr/src/pgsql (other paths are
- possible).
- o The runtime path is /usr/local/pgsql (other paths
- are possible).
-
- Commands were tested on RedHat Linux version 5.2
- using the tcsh shell. Except where noted, they will
- probably work on most systems. Commands like ps and
- tar may vary wildly between platforms on what options
- you should use. Use common sense before typing in
- these commands.
- Our Makefiles require GNU make (called ?gmake? in this
- document). They will not work with non-GNU make
- programs. If you have GNU make installed under the
- name ?make? instead of ?gmake?, then you will use the
- command make instead. That's OK, but you need to have
- the GNU form of make to succeed with an installation.
-
-Requirements to Run Postgres
-
- Up to date information on supported platforms is at
- http://www.postgresql.org/docs/admin/install.htm
- (http://www.postgresql.org/docs/admin/install.htm).
- In general, most Unix-compatible platforms with
- modern libraries should be able to run Postgres.
- Although the minimum required memory for running
- Postgres is as little as 8MB, there are noticable
- improvements in runtimes for the regression tests
- when expanding memory up to 96MB on a relatively fast
- dual-processor system running X-Windows. The rule is
- you can never have too much memory.
- Check that you have sufficient disk space. You will
- need about 30 Mbytes for /usr/src/pgsql, about 5
- Mbytes for /usr/local/pgsql (excluding your database)
- and 1 Mbyte for an empty database. The database will
- temporarily grow to about 20 Mbytes during the
- regression tests. You will also need about 3 Mbytes
- for the distribution tar file.
- We therefore recommend that during installation and
- testing you have well over 20 Mbytes free under
- /usr/local and another 25 Mbytes free on the disk
- partition containing your database. Once you delete
- the source files, tar file and regression database,
- you will need 2 Mbytes for /usr/local/pgsql, 1 Mbyte
- for the empty database, plus about five times the
- space you would require to store your database data
- in a flat file.
- To check for disk space, use
-
- $ df -k
-
-
-
+ ------------------------------------------------------------------------
+
+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 document.
+
+ ------------------------------------------------------------------------
+
+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 the Section called Supported Platforms 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 prerequisites exist for building PostgreSQL:
+
+ * 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. If you
+ are reading this, you probably already got past that hurdle.
+
+ * The GNU Readline library (for comfortable line editing and command
+ history retrieval) will automatically be used if found. You might wish
+ to install it before proceeding, but it is not essential. (On NetBSD,
+ the "libedit" library is readline-compatible and is used if
+ "libreadline" is not found.)
+
+ * GNU Flex and Bison are needed to build from scratch, but they are *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 Flex 2.5.4 or later and Bison 1.28 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.
+
+ * To build on Windows NT or Windows 2000 you need the Cygwin and cygipc
+ packages. See the file "doc/FAQ_MSWIN" for details.
+
+If you need to get a GNU package, you can find it at your local GNU mirror
+site (see http://www.gnu.org/order/ftp.html for a list) or at
+ftp://ftp.gnu.org/gnu/.
+
+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 "df" command to check for disk
+space.
+
+ ------------------------------------------------------------------------
+
+If You Are Upgrading
+
+The internal data storage format changes with new releases of PostgreSQL.
+Therefore, if you are upgrading an existing installation that does not have
+a version number "7.2.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.
+
+ 1. 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.
+
+ 2. To dump your database installation, type:
+
+ pg_dumpall > outputfile
+
+ If you need to preserve OIDs (such as when using them as foreign keys),
+ then use the "-o" option when running "pg_dumpall".
+
+ "pg_dumpall" does not save large objects. Check the Administrator's
+ Guide if you need to do this.
+
+ Make sure that you use the "pg_dumpall" command from the version you
+ are currently running. 7.2's "pg_dumpall" should not be used on older
+ databases.
+
+ 3. If you are installing the new version at the same location as the old
+ one then shut down the old server, at the latest before you install the
+ new files:
+
+ kill -INT `cat /usr/local/pgsql/data/postmaster.pid`
+
+ Versions prior to 7.0 do not have this "postmaster.pid" file. If you
+ are using such a version you must find out the process id of the server
+ yourself, for example by typing "ps ax | grep postmaster", and supply
+ it to the "kill" command.
+
+ On systems that have PostgreSQL started at boot time, there is probably
+ a start-up file that will accomplish the same thing. For example, on a
+ Red Hat Linux system one might find that
+
+ /etc/rc.d/init.d/postgresql stop
+
+ works. Another possibility is "pg_ctl stop".
+
+ 4. 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 7.2, 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.
+
+You can also install the new version in parallel with the old one to
+decrease the downtime. These topics are discussed at length in the
+Administrator's Guide, which you are encouraged to read in any case.
+
+ ------------------------------------------------------------------------
Installation Procedure
- Postgres Installation
- For a fresh install or upgrading from previous
- releases of Postgres:
- 1. Read any last minute information and platform
- specific porting notes. There are some platform
- specific notes at the end of this file for
- Ultrix4.x, Linux, BSD/OS and NeXT. There are other
- files in directory /usr/src/pgsql/doc, including
- files FAQ-Irix and FAQ-Linux. Also look in
- directory ftp://ftp.postgresql.org/pub. If there
- is a file called INSTALL in this directory then
- this file will contain the latest installation
- information.
- Please note that a "tested" platform in the list
- given earlier simply means that someone went to
- the effort at some point of making sure that a
- Postgres distribution would compile and run on
- this platform without modifying the code. Since
- the current developers will not have access to all
- of these platforms, some of them may not compile
- cleanly and pass the regression tests in the
- current release due to minor problems. Any such
- known problems and their solutions will be posted
- in ftp://ftp.postgresql.org/pub/INSTALL.
- 2. Create the Postgres superuser account (postgres is
- commonly used) if it does not already exist.
- The owner of the Postgres files can be any
- unprivileged user account. It must not be root,
- bin, or any other account with special access
- rights, as that would create a security risk.
- 3. Log in to the Postgres superuser account. Most of
- the remaining steps in the installation will
- happen in this account.
- 4. Ftp file
- ftp://ftp.postgresql.org/pub/postgresql-v6.5.tar.-
- gz
- (ftp://ftp.postgresql.org/pub/postgresql-v6.5.tar-
- .gz) from the Internet. Store it in your home
- directory.
- 5. Some platforms use flex. If your system uses flex
- then make sure you have a good version. To check,
- type
- $ flex --version
- If the flex command is not found then you
- probably do not need it. If the version is 2.5.2
- or 2.5.4 or greater then you are okay. If it is
- 2.5.3 or before 2.5.2 then you will have to
- upgrade flex. You may get it at
- ftp://prep.ai.mit.edu/pub/gnu/flex-2.5.4.tar.gz.
- If you need flex and don't have it or have the
- wrong version, then you will be told so when you
- attempt to compile the program. Feel free to skip
- this step if you aren't sure you need it. If you
- do need it then you will be told to
- install/upgrade flex when you try to compile
- Postgres.
- You may want to do the entire flex installation
- from the root account, though that is not
- absolutely necessary. Assuming that you want the
- installation to place files in the usual default
- areas, type the following:
- $ su -
- $ cd /usr/local/src
- ftp prep.ai.mit.edu
- ftp> cd /pub/gnu/
- ftp> binary
- ftp> get flex-2.5.4.tar.gz
- ftp> quit
- $ gunzip -c flex-2.5.4.tar.gz | tar xvf -
- $ cd flex-2.5.4
- $ configure --prefix=/usr
- $ gmake
- $ gmake check
- # You must be root when typing the next line:
- $ gmake install
- $ cd /usr/local/src
- $ rm -rf flex-2.5.4
- This will update files /usr/man/man1/flex.1,
- /usr/bin/flex, /usr/lib/libfl.a,
- /usr/include/FlexLexer.h and will add a link
- /usr/bin/flex++ which points to flex.
- 6. If you are not upgrading an existing system then
- skip to step 9. If you are upgrading an existing
- system then back up your database. For alpha- and
- beta-level releases, the database format is liable
- to change, often every few weeks, with no notice
- besides a quick comment in the HACKERS mailing
- list. Full releases always require a dump/reload
- from previous releases. It is therefore a bad idea
- to skip this step.
-
- Tip: Do not use the pg_dumpall script from v6.0
- or everything will be owned by the Postgres
- super user.
-
- To dump your fairly recent post-v6.0 database
- installation, type
- $ pg_dumpall > db.out
- To use the latest pg_dumpall script on your
- existing older database before upgrading Postgres,
- pull the most recent version of pg_dumpall from
- the new distribution:
- $ cd
- $ gunzip -c postgresql-v6.5.tar.gz \
- | tar xvf - src/bin/pg_dump/pg_dumpall
- $ chmod a+x src/bin/pg_dump/pg_dumpall
- $ src/bin/pg_dump/pg_dumpall > db.out
- $ rm -rf src
- If you wish to preserve object id's (oids), then
- use the -o option when running pg_dumpall.
- However, unless you have a special reason for
- doing this (such as using OIDs as keys in tables),
- don't do it.
- If the pg_dumpall command seems to take a long
- time and you think it might have died, then, from
- another terminal, type
- $ ls -l db.out
- several times to see if the size of the file is
- growing.
- Please note that if you are upgrading from a
- version prior to Postgres95 v1.09 then you must
- back up your database, install Postgres95 v1.09,
- restore your database, then back it up again. You
- should also read the release notes which should
- cover any release-specific issues.
-
- Caution
- You must make sure that your database is not
- updated in the middle of your backup. If
- necessary, bring down postmaster, edit the
- permissions in file
- /usr/local/pgsql/data/pg_hba.conf to allow
- only you on, then bring postmaster back up.
-
-
-
- 7. If you are upgrading an existing system then kill
- the postmaster. Type
- $ ps -ax | grep postmaster
- This should list the process numbers for a number
- of processes. Type the following line, with pid
- replaced by the process id for process postmaster.
- (Do not use the id for process "grep postmaster".)
- Type
- $ kill pid
- to actually stop the process.
-
- Tip: On systems which have Postgres started at
- boot time, there is probably a startup file
- which will accomplish the same thing. For
- example, on my Linux system I can type
- $ /etc/rc.d/init.d/postgres.init stop
- to halt Postgres.
-
- 8. If you are upgrading an existing system then move
- the old directories out of the way. If you are
- short of disk space then you may have to back up
- and delete the directories instead. If you do
- this, save the old database in the
- /usr/local/pgsql/data directory tree. At a
- minimum, save file
- /usr/local/pgsql/data/pg_hba.conf.
- Type the following:
- $ su -
- $ cd /usr/src
- $ mv pgsql pgsql_6_0
- $ cd /usr/local
- $ mv pgsql pgsql_6_0
- $ exit
- If you are not using /usr/local/pgsql/data as
- your data directory (check to see if environment
- variable PGDATA is set to something else) then you
- will also want to move this directory in the same
- manner.
- 9. Make new source and install directories. The
- actual paths can be different for your
- installation but you must be consistent throughout
- this procedure.
-
- Note: There are two places in this installation
- procedure where you will have an opportunity to
- specify installation locations for programs,
- libraries, documentation, and other files.
- Usually it is sufficient to specify these at the
- gmake install stage of installation.
-
- Type
- $ su
- $ cd /usr/src
- $ mkdir pgsql
- $ chown postgres:postgres pgsql
- $ cd /usr/local
- $ mkdir pgsql
- $ chown postgres:postgres pgsql
- $ exit
- 10. Unzip and untar the new source file. Type
- $ cd /usr/src/pgsql
- $ gunzip -c ~/postgresql-v6.5.tar.gz | tar xvf -
- 11. Configure the source code for your system. It
- is this step at which you can specify your actual
- installation path for the build process (see the
- --prefix option below). Type
- $ cd /usr/src/pgsql/src
- $ ./configure [ options ]
- a. Among other chores, the configure script
- selects a system-specific "template" file
- from the files provided in the template
- subdirectory. If it cannot guess which one to
- use for your system, it will say so and exit.
- In that case you'll need to figure out which
- one to use and run configure again, this time
- giving the --with-template=TEMPLATE option to
- make the right file be chosen.
-
- Please Report Problems: If your system is not
- automatically recognized by configure and
- you have to do this, please send email to
- scrappy@hub.org (mailto:scrappy@hub.org)
- with the output of the program
- ./config.guess. Indicate what the template
- file should be.
-
- b. Choose configuration options. Check
- Configuration Options for details. However,
- for a plain-vanilla first installation with
- no extra options like multi-byte character
- support or locale collation support it may be
- adequate to have chosen the installation
- areas and to run configure without extra
- options specified. The configure script
- accepts many additional options that you can
- use if you don't like the default
- configuration. To see them all, type
- ./configure --help
- Some of the more commonly used ones are:
- --prefix=BASEDIR Selects a different
- base directory for the
- installation of the
- Postgres configuration.
- The default is
- /usr/local/pgsql.
- --with-template=TEMPLATE
- Use template file
- TEMPLATE - the template
- files are assumed
- to be in the directory
- src/template, so
- look there for proper values.
- --with-tcl Build interface
- libraries and programs requiring
- Tcl/Tk, including
- libpgtcl, pgtclsh, and pgtksh.
- --with-perl Build the Perl
- interface library.
- --with-odbc Build the ODBC
- driver package.
- --enable-hba Enables Host Based
- Authentication (DEFAULT)
- --disable-hba Disables Host Based
- Authentication
- --enable-locale Enables USE_LOCALE
- --enable-cassert Enables
- ASSERT_CHECKING
- --with-CC=compiler
- Use a specific C
- compiler that the configure
- script cannot find.
- --with-CXX=compiler
- --without-CXX
- Use a specific C++
- compiler that the configure
- script cannot find,
- or exclude C++ compilation
- altogether. (This
- only affects libpq++ at
- present.)
- c. Here is the configure script used on a Sparc
- Solaris 2.5 system with /opt/postgres
- specified as the installation base directory:
- $ ./configure --prefix=/opt/postgres \
- --with-template=sparc_solaris-gcc
- --with-pgport=5432 \
- --enable-hba --disable-locale
-
- Tip: Of course, you may type these three
- lines all on the same line.
-
- 12. Install the man and HTML documentation. Type
- $ cd /usr/src/pgsql/doc
- $ gmake install
- The documentation is also available in Postscript
- format. Look for files ending with .ps.gz in the
- same directory.
- 13. Compile the program. Type
- $ cd /usr/src/pgsql/src
- $ gmake all >& make.log &
- $ tail -f make.log
- The last line displayed will hopefully be
- All of PostgreSQL is successfully made. Ready to
- install.
- Remember, ?gmake? may be called ?make? on your system.
- At this point, or earlier if you wish, type
- control-C to get out of tail. (If you have
- problems later on you may wish to examine file
- make.log for warning and error messages.)
-
- Note: You will probably find a number of warning
- messages in make.log. Unless you have problems
- later on, these messages may be safely ignored.
-
- If the compiler fails with a message stating that
- the flex command cannot be found then install flex
- as described earlier. Next, change directory back
- to this directory, type
- $ gmake clean
- then recompile again.
- Compiler options, such as optimization and
- debugging, may be specified on the command line
- using the COPT variable. For example, typing
- $ gmake COPT="-g" all >& make.log &
- would invoke your compiler's -g option in all
- steps of the build. See src/Makefile.global.in for
- further details.
- 14. Install the program. Type
- $ cd /usr/src/pgsql/src
- $ gmake install >& make.install.log &
- $ tail -f make.install.log
- The last line displayed will be
- gmake[1]: Leaving directory
- `/usr/src/pgsql/src/man'
- At this point, or earlier if you wish, type
- control-C to get out of tail. Remember, ?gmake? may
- be called ?make? on your system.
- 15. If necessary, tell your system how to find
- the new shared libraries. You can do one of the
- following, preferably the first:
- a. As root, edit file /etc/ld.so.conf. Add a
- line
- /usr/local/pgsql/lib
- to the file. Then run command /sbin/ldconfig.
- b. In a bash shell, type
- export
- LD_LIBRARY_PATH=/usr/local/pgsql/lib
- c. In a csh shell, type
- setenv LD_LIBRARY_PATH
- /usr/local/pgsql/lib
- Please note that the above commands may vary
- wildly for different operating systems. Check the
- platform specific notes, such as those for
- Ultrix4.x or and for non-ELF Linux.
- If, when you create the database, you get the
- message
- pg_id: can't load library 'libpq.so'
- then the above step was necessary. Simply do this
- step, then try to create the database again.
- 16. If you used the --with-perl option to
- configure, check the install log to see whether
- the Perl module was actually installed. If you've
- followed our advice to make the Postgres files be
- owned by an unprivileged userid, then the Perl
- module won't have been installed, for lack of
- write privileges on the Perl library directories.
- You can complete its installation, either now or
- later, by becoming the user that does own the Perl
- library (often root) (via su) and doing
- $ cd /usr/src/pgsql/src/interfaces/perl5
- $ gmake install
-
-
- 17. If it has not already been done, then prepare
- account postgres for using Postgres. Any account
- that will use Postgres must be similarly prepared.
- There are several ways to influence the runtime
- environment of the Postgres server. Refer to the
- Administrator's Guide for more information.
-
- Note: The following instructions are for a
- bash/sh shell. Adapt accordingly for other
- shells.
-
-
- a. Add the following lines to your login
- environment: shell, ~/.bash_profile:
- PATH=$PATH:/usr/local/pgsql/bin
- MANPATH=$MANPATH:/usr/local/pgsql/man
- PGLIB=/usr/local/pgsql/lib
- PGDATA=/usr/local/pgsql/data
- export PATH MANPATH PGLIB PGDATA
-
-
- b. Several regression tests could fail if the
- user's locale collation scheme is different
- from that of standard C locale.
- If you configure and compile Postgres with
- the --enable-locale option then set locale
- environment to C (or unset all LC_*
- variables) by putting these additional lines
- to your login environment before starting
- postmaster:
- LC_COLLATE=C
- LC_CTYPE=C
- LC_COLLATE=C
- export LC_COLLATE LC_CTYPE LC_COLLATE
-
-
-
-
-
- c. Make sure that you have defined these
- variables before continuing with the
- remaining steps. The easiest way to do this
- is to type:
- $ source ~/.bash_profile
-
-
- 18. Create the database installation from your
- Postgres superuser account (typically account
- postgres). Do not do the following as root! This
- would be a major security hole. Type
- $ initdb
- 19. Set up permissions to access the database
- system. Do this by editing file
- /usr/local/pgsql/data/pg_hba.conf. The
- instructions are included in the file. (If your
- database is not located in the default location,
- i.e. if PGDATA is set to point elsewhere, then the
- location of this file will change accordingly.)
- This file should be made read only again once you
- are finished. If you are upgrading from v6.0 or
- later you can copy file pg_hba.conf from your old
- database on top of the one in your new database,
- rather than redoing the file from scratch.
- 20. Briefly test that the backend will start and
- run by running it from the command line.
- a. Start the postmaster daemon running in the
- background by typing
- $ cd
- $ postmaster -i
- b. Create a database by typing
- $ createdb
- c. Connect to the new database:
- $ psql
- d. And run a sample query:
- postgres=> SELECT datetime 'now';
- e. Exit psql:
- postgres=> \q
- f. Remove the test database (unless you will
- want to use it later for other tests):
- $ destroydb
- 21. Run postmaster in the background from your
- Postgres superuser account (typically account
- postgres). Do not run postmaster from the root
- account!
- Usually, you will want to modify your computer so
- that it will automatically start postmaster
- whenever it boots. It is not required; the
- Postgres server can be run successfully from
- non-privileged accounts without root intervention.
- Here are some suggestions on how to do this,
- contributed by various users.
- Whatever you do, postmaster must be run by the
- Postgres superuser (postgres?) and not by root.
- This is why all of the examples below start by
- switching user (su) to postgres. These commands
- also take into account the fact that environment
- variables like PATH and PGDATA may not be set
- properly. The examples are as follows. Use them
- with extreme caution.
- o If you are installing from a non-privileged
- account and have no root access, then start the
- postmaster and send it to the background:
- $ cd
- $ nohup postmaster > regress.log 2>&1 &
- o Edit file rc.local on NetBSD or file rc2.d on
- SPARC Solaris 2.5.1 to contain the following
- single line:
- su postgres -c "/usr/local/pgsql/bin/postmaster
- -S -D /usr/local/pgsql/data"
- o In FreeBSD 2.2-RELEASE edit
- /usr/local/etc/rc.d/pgsql.sh to contain the
- following lines and make it chmod 755 and chown
- root:bin.
- #!/bin/sh
- [ -x /usr/local/pgsql/bin/postmaster ] && {
- su -l pgsql -c 'exec
- /usr/local/pgsql/bin/postmaster
- -D/usr/local/pgsql/data
- -S -o -F > /usr/local/pgsql/errlog' &
- echo -n ' pgsql'
- }
- You may put the line breaks as shown above. The
- shell is smart enough to keep parsing beyond
- end-of-line if there is an expression unfinished.
- The exec saves one layer of shell under the
- postmaster process so the parent is init.
- o In RedHat Linux add a file
- /etc/rc.d/init.d/postgres.init which is based on
- the example in contrib/linux/. Then make a
- softlink to this file from
- /etc/rc.d/rc5.d/S98postgres.init.
- o In RedHat Linux edit file /etc/inittab to add the
- following as a single line:
- pg:2345:respawn:/bin/su - postgres -c
- "/usr/local/pgsql/bin/postmaster
- -D/usr/local/pgsql/data
- >> /usr/local/pgsql/server.log 2>&1
- </dev/null"
- (The author of this example says this example
- will revive the postmaster if it dies, but he
- doesn't know if there are other side effects.)
- 22. Run the regression tests. The file
- /usr/src/pgsql/src/test/regress/README has
- detailed instructions for running and interpreting
- the regression tests. A short version follows
- here:
- a. Type
- $ cd /usr/src/pgsql/src/test/regress
- $ gmake clean
- $ gmake all runtest
- You do not need to type gmake clean if this
- is the first time you are running the tests.
- You should get on the screen (and also
- written to file ./regress.out) a series of
- statements stating which tests passed and
- which tests failed. Please note that it can
- be normal for some tests to "fail" on some
- platforms. The script says a test has failed
- if there is any difference at all between the
- actual output of the test and the expected
- output. Thus, tests may "fail" due to minor
- differences in wording of error messages,
- small differences in floating-point roundoff,
- etc, between your system and the regression
- test reference platform. "Failures" of this
- type do not indicate a problem with Postgres.
- The file ./regression.diffs contains the
- textual differences between the actual test
- output on your machine and the "expected"
- output (which is simply what the reference
- system produced). You should carefully
- examine each difference listed to see whether
- it appears to be a significant issue.
- For example,
- o For a i686/Linux-ELF platform, no tests
- failed since this is the v6.5 regression
- testing reference platform.
- Even if a test result clearly indicates a
- real failure, it may be a localized problem
- that will not affect you. An example is that
- the int8 test will fail, producing obviously
- incorrect output, if your machine and C
- compiler do not provide a 64-bit integer data
- type (or if they do but configure didn't
- discover it). This is not something to worry
- about unless you need to store 64-bit
- integers.
- Conclusion? If you do see failures, try to
- understand the nature of the differences and
- then decide if those differences will affect
- your intended use of Postgres. The regression
- tests are a helpful tool, but they may
- require some study to be useful.
- After running the regression tests, type
- $ destroydb regression
- $ cd /usr/src/pgsql/src/test/regress
- $ gmake clean
- to recover the disk space used for the
- tests. (You may want to save the
- regression.diffs file in another place before
- doing this.)
- 23. If you haven't already done so, this would be
- a good time to modify your computer to do regular
- maintainence. The following should be done at
- regular intervals:
-
- Minimal Backup Procedure
- 1. Run the SQL command VACUUM. This will clean
- up your database.
- 2. Back up your system. (You should probably
- keep the last few backups on hand.) Preferably,
- no one else should be using the system at the
- time.
-
- Ideally, the above tasks should be done by a
- shell script that is run nightly or weekly by
- cron. Look at the man page for crontab for a
- starting point on how to do this. (If you do it,
- please e-mail us a copy of your shell script. We
- would like to set up our own systems to do this
- too.)
- 24. If you are upgrading an existing system then
- reinstall your old database. Type
- $ cd
- $ psql -e template1 < db.out
- If your pre-v6.2 database uses either path or
- polygon geometric data types, then you will need
- to upgrade any columns containing those types. To
- do so, type (from within psql)
- UPDATE FirstTable SET PathCol =
- UpgradePath(PathCol);
- UPDATE SecondTable SET PathCol =
- UpgradePath(PathCol);
- ...
- VACUUM;
- UpgradePath() checks to see that a path value is
- consistant with the old syntax, and will not
- update a column which fails that examination.
- UpgradePoly() cannot verify that a polygon is in
- fact from an old syntax, but RevertPoly() is
- provided to reverse the effects of a mis-applied
- upgrade.
- 25. If you are a new user, you may wish to play
- with Postgres as described below.
- 26. Clean up after yourself. Type
- $ rm -rf /usr/src/pgsql_6_5
- $ rm -rf /usr/local/pgsql_6_5
- # Also delete old database directory tree if it is
- not in
- # /usr/local/pgsql_6_5/data
- $ rm ~/postgresql-v6.5.tar.gz
- 27. You will probably want to print out the
- documentation. If you have a Postscript printer,
- or have your machine already set up to accept
- Postscript files using a print filter, then to
- print the User's Guide simply type
- $ cd /usr/local/pgsql/doc
- $ gunzip user.ps.tz | lpr
- Here is how you might do it if you have
- Ghostscript on your system and are writing to a
- laserjet printer.
- $ alias gshp='gs -sDEVICE=laserjet -r300
- -dNOPAUSE'
- $ export
- GS_LIB=/usr/share/ghostscript:/usr/share/ghostscr-
- ipt/fonts
- $ gunzip user.ps.gz
- $ gshp -sOUTPUTFILE=user.hp user.ps
- $ gzip user.ps
- $ lpr -l -s -r manpage.hp
- 28. The Postgres team wants to keep Postgres
- working on all of the supported platforms. We
- therefore ask you to let us know if you did or did
- not get Postgres to work on you system. Please
- send a mail message to pgsql-ports@postgresql.org
- (mailto:pgsql-ports@postgresql.org) telling us the
- following:
- o The version of Postgres (v6.5, 6.4.2, beta
- 981014, etc.).
- o Your operating system (i.e. RedHat v5.1 Linux
- v2.0.34).
- o Your hardware (SPARC, i486, etc.).
- o Did you compile, install and run the regression
- tests cleanly? If not, what source code did you
- change (i.e. patches you applied, changes you
- made, etc.), what tests failed, etc. It is normal
- to get many warning when you compile. You do not
- need to report these.
- 29. Now create, access and manipulate databases
- as desired. Write client programs to access the
- database server. In other words, enjoy!
-
-Playing with Postgres
-
- After Postgres is installed, a database system is
- created, a postmaster daemon is running, and the
- regression tests have passed, you'll want to see
- Postgres do something. That's easy. Invoke the
- interactive interface to Postgres, psql:
-
- % psql template1
-
- (psql has to open a particular database, but at this
- point the only one that exists is the template1
- database, which always exists. We will connect to it
- only long enough to create another one and switch to
- it.)
- The response from psql is:
-
- Welcome to the POSTGRESQL interactive sql monitor:
- Please read the file COPYRIGHT for copyright terms
- of POSTGRESQL
-
- type \? for help on slash commands
- type \q to quit
- type \g or terminate with semicolon to execute
- query
- You are currently connected to the database:
- template1
-
- template1=>
-
- Create the database foo:
-
- template1=> create database foo;
- CREATEDB
-
- (Get in the habit of including those SQL semicolons.
- Psql won't execute anything until it sees the
- semicolon or a "\g" and the semicolon is required to
- delimit multiple statements.)
- Now connect to the new database:
-
- template1=> \c foo
- connecting to new database: foo
-
- ("slash" commands aren't SQL, so no semicolon. Use \?
- to see all the slash commands.)
- And create a table:
-
- foo=> create table bar (i int4, c char(16));
- CREATE
-
- Then inspect the new table:
-
- foo=> \d bar
-
- Table = bar
- +----------------------------------+-----------------
- ------------------+-------+
- | Field |
- Type | Length|
- +----------------------------------+-----------------
- ------------------+-------+
- | i | int4
- | 4 |
- | c | (bp)char
- | 16 |
- +----------------------------------+-----------------
- ------------------+-------+
-
- And so on. You get the idea.
-
-The Next Step
-
- Questions? Bugs? Feedback? First, read the files in
- directory /usr/src/pgsql/doc/. The FAQ in this
- directory may be particularly useful.
- If Postgres failed to compile on your computer then
- fill out the form in file
- /usr/src/pgsql/doc/bug.template and mail it to the
- location indicated at the top of the form.
- Check on the web site at http://www.postgresql.org
- For more information on the various support mailing
- lists.
-
-Porting Notes
-
- Check for any platform-specific FAQs in the doc/
- directory of the source distribution.
-
-Chapter 4. Configuration Options
-
-Parameters for Configuration (configure)
-
- The full set of parameters available in configure
- can be obtained by typing
-
- $ ./configure --help
-
-
-
- The following parameters may be of interest to
- installers:
-
- Directory and file names:
- --prefix=PREFIX install
- architecture-independent files in PREFIX
- [/usr/local/pgsql]
- --bindir=DIR user executables in DIR
- [EPREFIX/bin]
- --libdir=DIR object code libraries in
- DIR [EPREFIX/lib]
- --includedir=DIR C header files in DIR
- [PREFIX/include]
- --mandir=DIR man documentation in DIR
- [PREFIX/man]
- Features and packages:
- --disable-FEATURE do not include FEATURE
- (same as --enable-FEATURE=no)
- --enable-FEATURE[=ARG] include FEATURE [ARG=yes]
- --with-PACKAGE[=ARG] use PACKAGE [ARG=yes]
- --without-PACKAGE do not use PACKAGE (same as
- --with-PACKAGE=no)
- --enable and --with options recognized:
- --with-template=template
- use operating system
- template file
- see template directory
- --with-includes=incdir site header files for
- tk/tcl, etc in DIR
- --with-libs=incdir also search for libraries
- in DIR
- --with-libraries=libdir also search for libraries
- in DIR
- --enable-locale enable locale support
- --enable-recode enable cyrillic recode
- support
- --with-mb=encoding enable multi-byte support
- --with-pgport=portnum change default startup port
- --with-maxbackends=n set default maximum number of
- server processes
- --with-tcl build Tcl interfaces and
- pgtclsh
- --with-tclconfig=tcldir tclConfig.sh and
- tkConfig.sh are in DIR
- --with-perl build Perl interface
- --with-odbc build ODBC driver package
- --with-odbcinst=odbcdir change default directory
- for odbcinst.ini
- --enable-cassert enable assertion checks
- (debugging)
- --with-CC=compiler use specific C compiler
- --with-CXX=compiler use specific C++ compiler
- --without-CXX prevent building C++ code
-
-
-
- Some systems may have trouble building a specific
- feature of Postgres. For example, systems with a
- damaged C++ compiler may need to specify
- --without-CXX to instruct the build procedure to skip
- construction of libpq++.
-
-Parameters for Building (make)
-
- Many installation-related parameters can be set in
- the building stage of Postgres installation.
- In most cases, these parameters should be placed in
- a file, Makefile.custom, intended just for that
- purpose. The default distribution does not contain
- this optional file, so you will create it using a
- text editor of your choice. When upgrading
- installations, you can simply copy your old
- Makefile.custom to the new installation before doing
- the build.
-
- make [ variable=value [,...] ]
-
-
-
- A few of the many variables which can be specified
- are:
-
- POSTGRESDIR
- Top of the installation tree.
-
- BINDIR
- Location of applications and utilities.
-
- LIBDIR
- Location of object libraries, including shared
- libraries.
-
- HEADERDIR
- Location of include files.
-
- ODBCINST
- Location of installation-wide psqlODBC (ODBC)
- configuration file.
-
- There are other optional parameters which are not as
- commonly used. Many of those listed below are
- appropriate when doing Postgres server code
- development.
-
- CFLAGS
- Set flags for the C compiler. Should be assigned
- with "+=" to retain relevant default parameters.
-
- YFLAGS
- Set flags for the yacc/bison parser. -v might be
- used to help diagnose problems building a new
- parser. Should be assigned with "+=" to retain
- relevant default parameters.
-
- USE_TCL
- Enable Tcl interface building.
-
- HSTYLE
- DocBook HTML style sheets for building the
- documentation from scratch. Not used unless you
- are developing new documentation from the
- DocBook-compatible SGML source documents in
- doc/src/sgml/.
-
- PSTYLE
- DocBook style sheets for building printed
- documentation from scratch. Not used unless you
- are developing new documentation from the
- DocBook-compatible SGML source documents in
- doc/src/sgml/.
-
- Here is an example Makefile.custom for a PentiumPro
- Linux system:
-
- # Makefile.custom
- # Thomas Lockhart 1998-03-01
-
- POSTGRESDIR= /opt/postgres/current
- CFLAGS+= -m486 # -g -O0
- USE_TCL= true
- TCL_LIB= -ltcl
- X_LIBS= -L/usr/X11/lib
- TK_LIB= -ltk
-
- # documentation
-
- HSTYLE= /home/tgl/SGML/db118.d/docbook/html
- PSTYLE= /home/tgl/SGML/db118.d/docbook/print
-
-
-
-
-Locale Support
-
-
-
- Note: Written by Oleg Bartunov. See Oleg's web
- page (http://www.sai.msu.su/~megera/postgres/) for
- additional information on locale and Russian
- language support.
-
- While doing a project for a company in Moscow,
- Russia, I encountered the problem that postgresql had
- no support of national alphabets. After looking for
- possible workarounds I decided to develop support of
- locale myself. I'm not a C-programer but already had
- some experience with locale programming when I work
- with perl (debugging) and glimpse. After several days
- of digging through the Postgres source tree I made
- very minor corections to
- src/backend/utils/adt/varlena.c and
- src/backend/main/main.c and got what I needed! I did
- support only for LC_CTYPE and LC_COLLATE, but later
- LC_MONETARY was added by others. I got many messages
- from people about this patch so I decided to send it
- to developers and (to my surprise) it was
- incorporated into the Postgres distribution.
- People often complain that locale doesn't work for
- them. There are several common mistakes:
- o Didn't properly configure postgresql before
- compilation. You must run configure with
- --enable-locale option to enable locale support.
- Didn't setup environment correctly when starting
- postmaster. You must define environment variables
- LC_CTYPE and LC_COLLATE before running postmaster
- because backend gets information about locale from
- environment. I use following shell script
- (runpostgres):
- #!/bin/sh
-
- export LC_CTYPE=koi8-r
- export LC_COLLATE=koi8-r
- postmaster -B 1024 -S
- -D/usr/local/pgsql/data/ -o '-Fe'
-
- and run it from rc.local as
- /bin/su - postgres -c
- "/home/postgres/runpostgres"
-
-
- o Broken locale support in OS (for example, locale
- support in libc under Linux several times has
- changed and this caused a lot of problems). Latest
- perl has also support of locale and if locale is
- broken perl -v will complain something like:
- 8:17[mira]:~/WWW/postgres>setenv LC_CTYPE
- not_exist
- 8:18[mira]:~/WWW/postgres>perl -v
- perl: warning: Setting locale failed.
- perl: warning: Please check that your locale
- settings:
- LC_ALL = (unset),
- LC_CTYPE = "not_exist",
- LANG = (unset)
- are supported and installed on your system.
- perl: warning: Falling back to the standard
- locale ("C").
-
-
- o Wrong location of locale files! Possible locations
- include: /usr/lib/locale (Linux, Solaris),
- /usr/share/locale (Linux), /usr/lib/nls/loc (DUX
- 4.0). Check man locale to find the correct
- location. Under Linux I did a symbolic link between
- /usr/lib/locale and /usr/share/locale to be sure
- that the next libc will not break my locale.
-
-
-What are the Benefits?
-
- You can use ~* and order by operators for strings
- contain characters from national alphabets.
- Non-english users definitely need that. If you won't
- use locale stuff just undefine the USE_LOCALE
- variable.
-
-What are the Drawbacks?
-
- There is one evident drawback of using locale - its
- speed! So, use locale only if you really need it.
-
-Kerberos Authentication
-
- Kerberos is an industry-standard secure
- authentication system suitable for distributed
- computing over a public network.
-
-Availability
-
- The Kerberos authentication system is not
- distributed with Postgres. Versions of Kerberos are
- typically available as optional software from
- operating system vendors. In addition, a source code
- distribution may be obtained through MIT Project
- Athena (ftp://athena-dist.mit.edu).
-
- Note: You may wish to obtain the MIT version even
- if your vendor provides a version, since some
- vendor ports have been deliberately crippled or
- rendered non-interoperable with the MIT version.
-
- Users located outside the United States of America
- and Canada are warned that distribution of the actual
- encryption code in Kerberos is restricted by U. S.
- Government export regulations.
- Inquiries regarding your Kerberos should be directed
- to your vendor or MIT Project Athena
- (info-kerberos@athena.mit.edu). Note that FAQLs
- (Frequently-Asked Questions Lists) are periodically
- posted to the Kerberos mailing list
- (mailto:kerberos@ATHENA.MIT.EDU) (send mail to
- subscribe (mailto:kerberos-request@ATHENA.MIT.EDU)),
- and USENET news group (news:comp.protocols.kerberos).
-
-Installation
-
- Installation of Kerberos itself is covered in detail
- in the Kerberos Installation Notes . Make sure that
- the server key file (the srvtab or keytab) is somehow
- readable by the Postgres account.
- Postgres and its clients can be compiled to use
- either Version 4 or Version 5 of the MIT Kerberos
- protocols by setting the KRBVERS variable in the file
- src/Makefile.global to the appropriate value. You can
- also change the location where Postgres expects to
- find the associated libraries, header files and its
- own server key file.
- After compilation is complete, Postgres must be
- registered as a Kerberos service. See the Kerberos
- Operations Notes and related manual pages for more
- details on registering services.
-
-Operation
-
- After initial installation, Postgres should operate
- in all ways as a normal Kerberos service. For details
- on the use of authentication, see the PostgreSQL
- User's Guide reference sections for postmaster and
- psql.
- In the Kerberos Version 5 hooks, the following
- assumptions are made about user and service naming:
- o User principal names (anames) are assumed to
- contain the actual Unix/Postgres user name in the
- first component.
- o The Postgres service is assumed to be have two
- components, the service name and a hostname,
- canonicalized as in Version 4 (i.e., with all
- domain suffixes removed).
-
-
-
- Table 4-1. Kerberos Parameter Examples
- Parameter Example
- user frew@S2K.ORG
- user aoki/HOST=miyu.S2K.Berkeley.EDU@S2K.ORG
- host postgres_dbms/ucbvax@S2K.ORG
-
-
-
- Support for Version 4 will disappear sometime after
- the production release of Version 5 by MIT.
-
-Chapter 5. Release Notes
-
-Release 6.5
-
- This release marks a major step in the development
- team's mastery of the source code we inherited from
- Berkeley. You will see we are now easily adding major
- features, thanks to the increasing size and
- experience of our world-wide development team.
- Here is a brief summary of some of the more
- noticable changes:
-
- Multi-version concurrency control(MVCC)
- This removes our old table-level locking, and
- replaces it with a locking system that is superior
- to most commercial database systems. In a
- traditional system, each row that is modified is
- locked until committed, preventing reads by other
- users. MVCC uses the natural multi-version nature
- of PostgreSQL to allow readers to continue reading
- consistent data during writer activity. Writers
- continue to use the compact pg_log transaction
- system. This is all performed without having to
- allocate a lock for every row like traditional
- database systems. So, basically, we no longer are
- restricted by simple table-level locking; we have
- something better than row-level locking.
-
- Numeric data type
- We now have a true numeric data type, with
- user-specified precision.
-
- Temporary tables
- Temporary tables are guaranteed to have unique
- names within a database session, and are destroyed
- on session exit.
-
- New SQL features
- We now have CASE, INTERSECT, and EXCEPT statement
- support. We have new LIMIT/OFFSET, SET TRANSACTION
- ISOLATION LEVEL, SELECT ... FOR UPDATE, and an
- improved LOCK command.
-
- Speedups
- We continue to speed up PostgreSQL, thanks to the
- variety of talents within our team. We have sped
- up memory allocation, optimization, table joins,
- and row transfer routines.
-
- Ports
- We continue to expand our port list, this time
- including WinNT/ix86 and NetBSD/arm32.
-
- Interfaces
- Most interfaces have new versions, and existing
- functionality has been improved.
-
-
-Migration to v6.5
-
- A dump/restore using pg_dump or pg_dumpall is
- required for those wishing to migrate data from any
- previous release of Postgres.
- The new Multi-Version Concurrency Control (MVCC)
- features can give somewhat different behaviors in
- multi-user environments. Read and understand the
- following section to ensure that your existing
- applications will give you the behavior you need.
-
- Multi-Version Concurrency Control
- Because readers in 6.5 don't lock data, regardless
- of transaction isolation level, data read by one
- transaction can be overwritten by another. In the
- other words, if a row is returned by SELECT it
- doesn't mean that this row really exists at the time
- it is returned (i.e. sometime after the statement or
- transaction began) nor that the row is protected from
- deletion or updation by concurrent transactions
- before the current transaction does a commit or
- rollback.
- To ensure the actual existance of a row and protect
- it against concurrent updates one must use SELECT FOR
- UPDATE or an appropriate LOCK TABLE statement. This
- should be taken into account when porting
- applications from previous releases of Postgres and
- other environments.
- Keep above in mind if you are using contrib/refint.*
- triggers for referential integrity. Additional
- technics are required now. One way is to use LOCK
- parent_table IN SHARE ROW EXCLUSIVE MODE command if a
- transaction is going to update/delete a primary key
- and use LOCK parent_table IN SHARE MODE command if a
- transaction is going to update/insert a foreign key.
-
- Note: Note that if you run a transaction in
- SERIALIZABLE mode then you must execute LOCK
- commands above before execution of any DML
- statement
- (SELECT/INSERT/DELETE/UPDATE/FETCH/COPY_TO) in the
- transaction.
-
-
- These inconveniences will disappear in the future
- when the ability to read dirty (uncommitted) data
- (regardless of isolation level) and true referential
- integrity will be implemented.
-
-Detailed Change List
-
-
-
- Bug Fixes
- ---------
- Fix text<->float8 and text<->float4 conversion
- functions(Thomas)
- Fix for creating tables with mixed-case
- constraints(Billy)
- Change exp()/pow() behavior to generate error on
- underflow/overflow(Jan)
- Fix bug in pg_dump -z
- Memory overrun cleanups(Tatsuo)
- Fix for lo_import crash(Tatsuo)
- Adjust handling of data type names to suppress double
- quotes(Thomas)
- Use type coersion for matching columns and
- DEFAULT(Thomas)
- Fix deadlock so it only checks once after one second
- of sleep(Bruce)
- Fixes for aggregates and PL/pgsql(Hiroshi)
- Fix for subquery crash(Vadim)
- Fix for libpq function PQfnumber and case-insensitive
- names(Bahman Rafatjoo)
- Fix for large object write-in-middle, no extra block,
- memory consumption(Tatsuo)
- Fix for pg_dump -d or -D and quote special
- characters in INSERT
- Repair serious problems with dynahash(Tom)
- Fix INET/CIDR portability problems
- Fix problem with selectivity error in ALTER TABLE ADD
- COLUMN(Bruce)
- Fix executor so mergejoin of different column types
- works(Tom)
- Fix for Alpha OR selectivity bug
- Fix OR index selectivity problem(Bruce)
- Fix so \d shows proper length for
- char()/varchar()(Ryan)
- Fix tutorial code(Clark)
- Improve destroyuser checking(Oliver)
- Fix for Kerberos(Rodney McDuff)
- Fix for dropping database while dirty buffers(Bruce)
- Fix so sequence nextval() can be
- case-sensitive(Bruce)
- Fix !!= operator
- Drop buffers before destroying database files(Bruce)
- Fix case where executor evaluates functions
- twice(Tatsuo)
- Allow sequence nextval actions to be
- case-sensitive(Bruce)
- Fix optimizer indexing not working for negative
- numbers(Bruce)
- Fix for memory leak in executor with fjIsNull
- Fix for aggregate memory leaks(Erik Riedel)
- Allow username containing a dash GRANT permissions
- Cleanup of NULL in inet types
- Clean up system table bugs(Tom)
- Fix problems of PAGER and \? command(Masaaki Sakaida)
- Reduce default multi-segment file size limit to
- 1GB(Peter)
- Fix for dumping of CREATE OPERATOR(Tom)
- Fix for backward scanning of cursors(Hiroshi Inoue)
- Fix for COPY FROM STDIN when using \i(Tom)
- Fix for subselect is compared inside an
- expression(Jan)
- Fix handling of error reporting while returning
- rows(Tom)
- Fix problems with reference to array types(Tom,Jan)
- Prevent UPDATE SET oid(Jan)
- Fix pg_dump so -t option can handle case-sensitive
- tablenames
- Fixes for GROUP BY in special cases(Tom, Jan)
- Fix for memory leak in failed queries(Tom)
- DEFAULT now supports mixed-case identifiers(Tom)
- Fix for multi-segment uses of DROP/RENAME table,
- indexes(Ole Gjerde)
-
- Enhancements
- ------------
- Add "vacuumdb" utility
- Speed up libpq by allocating memory better(Tom)
- EXPLAIN all indices used(Tom)
- Implement CASE, COALESCE, NULLIF expression(Thomas)
- New pg_dump table output format(Constantin)
- Add string min()/max() functions(Thomas)
- Extend new type coersion techniques to
- aggregates(Thomas)
- New moddatetime contrib(Terry)
- Update to pgaccess 0.96(Constantin)
- Add routines for single-byte "char" type(Thomas)
- Improved substr() function(Thomas)
- Improved multi-byte handling(Tatsuo)
- Multi-version concurrency control/MVCC(Vadim)
- New Serialized mode(Vadim)
- Fix for tables over 2gigs(Peter)
- New SET TRANSACTION ISOLATION LEVEL(Vadim)
- New LOCK TABLE IN ... MODE(Vadim)
- Update ODBC driver(Byron)
- New NUMERIC data type(Jan)
- New SELECT FOR UPDATE(Vadim)
- Handle "NaN" and "Infinity" for input values(Jan)
- Improved date/year handling(Thomas)
- Improved handling of backend connections(Magnus)
- New options ELOG_TIMESTAMPS and USE_SYSLOG options
- for log files(Massimo)
- New TCL_ARRAYS option(Massimo)
- New INTERSECT and EXCEPT(Stefan)
- New pg_index.indisprimary for primary key
- tracking(D'Arcy)
- New pg_dump option to allow dropping of tables before
- creation(Brook)
- Speedup of row output routines(Tom)
- New READ COMMITTED isolation level(Vadim)
- New TEMP tables/indexes(Bruce)
- Prevent sorting if result is already sorted(Jan)
- New memory allocation optimization(Jan)
- Allow psql to do \p\g(Bruce)
- Allow multiple rule actions(Jan)
- Added LIMIT/OFFSET functionality(Jan)
- Improve optimizer when joining a large number of
- tables(Bruce)
- New intro to SQL from S. Simkovics' Master's Thesis
- (Stefan, Thomas)
- New intro to backend processing from S. Simkovics'
- Master's Thesis (Stefan)
- Improved int8 support(Ryan Bradetich, Thomas, Tom)
- New routines to convert between int8 and text/varchar
- types(Thomas)
- New bushy plans, where meta-tables are joined(Bruce)
- Enable right-hand queries by default(Bruce)
- Allow reliable maximum number of backends to be set
- at configure time
- (--with-maxbackends and postmaster switch (-N
- backends))(Tom)
- GEQO default now 10 tables because of optimizer
- speedups(Tom)
- Allow NULL=Var for MS-SQL portability(Michael, Bruce)
- Modify contrib check_primary_key() so either
- "automatic" or "dependent"(Anand)
- Allow psql \d on a view show query(Ryan)
- Speedup for LIKE(Bruce)
- Ecpg fixes/features, see
- src/interfaces/ecpg/ChangeLog file(Michael)
- JDBC fixes/features, see
- src/interfaces/jdbc/CHANGELOG(Peter)
- Make % operator have precedence like /(Bruce)
- Add new postgres -O option to allow system table
- structure changes(Bruce)
- Update contrib/pginterface/findoidjoins script(Tom)
- Major speedup in vacuum of deleted rows with
- indexes(Vadim)
- Allow non-SQL functions to run different versions
- based on arguments(Tom)
- Add -E option that shows actual queries sent by \dt
- and friends(Masaaki Sakaida)
- Add version number in startup banners for
- psql(Masaaki Sakaida)
- New contrib/vacuumlo removes large objects not
- referenced(Peter)
- New initialization for table sizes so non-vacuumed
- tables perform better(Tom)
- Improve error messages when a connection is
- rejected(Tom)
- Support for arrays of char() and varchar()
- fields(Massimo)
- Overhaul of hash code to increase reliability and
- performance(Tom)
- Update to PyGreSQL 2.4(D'Arcy)
- Changed debug options so -d4 and -d5 produce
- different node displays(Jan)
- New pg_options: pretty_plan, pretty_parse,
- pretty_rewritten(Jan)
- Better optimization statistics for system table
- access(Tom)
- Better handling of non-default block sizes(Massimo)
- Improve GEQO optimizer memory consumption(Tom)
- UNION now suppports ORDER BY of columns not in target
- list(Jan)
- Major libpq++ improvements(Vince Vielhaber)
-
- Source Tree Changes
- -------------------
- Improve port matching(Tom)
- Portability fixes for SunOS
- Add NT/Win32 backend port and enable dynamic
- loading(Magnus and Daniel Horak)
- New port to Cobalt Qube(Mips) running Linux(Tatsuo)
- Port to NetBSD/m68k(Mr. Mutsuki Nakajima)
- Port to NetBSD/sun3(Mr. Mutsuki Nakajima)
- Port to NetBSD/macppc(Toshimi Aoki)
- Fix for tcl/tk configuration(Vince)
- Removed CURRENT keyword for rule queries(Jan)
- NT dynamic loading now works(Daniel Horak)
- Add ARM32 support(Andrew McMurry)
- Better support for HPUX 11 and Unixware
- Improve file handling to be more uniform, prevent
- file descriptor leak(Tom)
- New install commands for plpgsql(Jan)
-
+ 1. Configuration
+
+ 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.
+
+ 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":
+
+ --prefix=PREFIX
+
+ 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.
+
+ --exec-prefix=EXEC-PREFIX
+
+ 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.
+
+ --bindir=DIRECTORY
+
+ Specifies the directory for executable programs. The default is
+ "EXEC-PREFIX/bin", which normally means "/usr/local/pgsql/bin".
+
+ --datadir=DIRECTORY
+
+ 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.
+
+ --sysconfdir=DIRECTORY
+
+ The directory for various configuration files, "PREFIX/etc" by
+ default.
+
+ --libdir=DIRECTORY
+
+ The location to install libraries and dynamically loadable
+ modules. The default is "EXEC-PREFIX/lib".
+
+ --includedir=DIRECTORY
+
+ The directory for installing C and C++ header files. The default
+ is "PREFIX/include".
+
+ --docdir=DIRECTORY
+
+ Documentation files, except "man" pages, will be installed into
+ this directory. The default is "PREFIX/doc".
+
+ --mandir=DIRECTORY
+
+ The man pages that come with PostgreSQL will be installed under
+ this directory, in their respective "manx" subdirectories. The
+ default is "PREFIX/man".
+
+ Note: 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".
+ 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 includedir
+ and are namespace-clean. The internal header files and the
+ server header files are installed into private directories
+ under includedir. See the Programmer's Guide for information
+ about how to get at the header files for each interface.
+ Finally, a private subdirectory will also be created, if
+ appropriate, under libdir for dynamically loadable modules.
+
+ --with-includes=DIRECTORIES
+
+ "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 "--with-libraries" option.
+
+ Example: --with-includes=/opt/gnu/include:/usr/sup/include.
+
+ --with-libraries=DIRECTORIES
+
+ "DIRECTORIES" is a colon-separated list of directories to search
+ for libraries. You will probably have to use this option (and the
+ corresponding "--with-includes" option) if you have packages
+ installed in non-standard locations.
+
+ Example: --with-libraries=/opt/gnu/lib:/usr/sup/lib.
+
+ --enable-locale
+
+ Enables locale support. There is a performance penalty associated
+ with locale support, but if you are not in an English-speaking
+ environment you will most likely need this.
+
+ --enable-recode
+
+ Enables single-byte character set recode support. See the
+ Administrator's Guide about this feature.
+
+ --enable-multibyte
+
+ Allows the use of multibyte character encodings (including
+ Unicode) and character set encoding conversion. Read the
+ Administrator's Guide for details.
+
+ 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.
+
+ --enable-nls[=LANGUAGES]
+
+ 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. Some operating systems have this built-in (e.g., Linux,
+ NetBSD, Solaris), for other systems you can download an add-on
+ package from here: http://www.postgresql.org/~petere/gettext.html.
+ 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.
+
+ --with-pgport=NUMBER
+
+ 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.
+
+ --with-CXX
+
+ Build the C++ interface library.
+
+ --with-perl
+
+ Build the Perl interface module. The Perl interface will be
+ installed at the usual place for Perl modules (typically under
+ "/usr/lib/perl"), so you must have root access to perform the
+ installation step (see step 4). You need to have Perl 5 installed
+ to use this option.
+
+ --with-python
+
+ Build the Python interface module. You need to have root access to
+ be able to install the Python module at its default place
+ ("/usr/lib/pythonx.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.
+
+ --with-tcl
+
+ Builds components that require Tcl/Tk, which are libpgtcl,
+ pgtclsh, pgtksh, PgAccess, and PL/Tcl. But see below about
+ "--without-tk".
+
+ --without-tk
+
+ If you specify "--with-tcl" and this option, then programs that
+ require Tk (pgtksh and PgAccess) will be excluded.
+
+ --with-tclconfig=DIRECTORY, --with-tkconfig=DIRECTORY
+
+ Tcl/Tk installs the files "tclConfig.sh" and "tkConfig.sh", 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.
+
+ --enable-odbc
+
+ 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
+ Programmer's Guide.
+
+ --with-iodbc
+
+ Build the ODBC driver for use with iODBC.
+
+ --with-unixodbc
+
+ Build the ODBC driver for use with unixODBC.
+
+ --with-odbcinst=DIRECTORY
+
+ Specifies the directory where the ODBC driver will expect its
+ "odbcinst.ini" configuration file. The default is
+ "/usr/local/pgsql/etc" or whatever you specified as
+ "--sysconfdir". It should be arranged that the driver reads the
+ same file as the driver manager.
+
+ If either the option "--with-iodbc" or the option
+ "--with-unixodbc" is used, this option will be ignored because in
+ that case the driver manager handles the location of the
+ configuration file.
+
+ --with-java
+
+ Build the JDBC driver and associated Java packages. This option
+ requires Ant to be installed (as well as a JDK, of course). Refer
+ to the JDBC driver documentation in the Programmer's Guide for
+ more information.
+
+ --with-krb4[=DIRECTORY], --with-krb5[=DIRECTORY]
+
+ Build with support for Kerberos authentication. You can use either
+ Kerberos version 4 or 5, but not both. The "DIRECTORY" argument
+ specifies the root directory of the Kerberos installation;
+ "/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 "--with-includes" and "--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., "/usr/lib"),
+ then you can leave off the argument.
+
+ "configure" will check for the required header files and libraries
+ to make sure that your Kerberos installation is sufficient before
+ proceeding.
+
+ --with-krb-srvnam=NAME
+
+ The name of the Kerberos service principal. postgres is the
+ default. There's probably no reason to change this.
+
+ --with-openssl[=DIRECTORY]
+
+ Build with support for SSL (encrypted) connections. This requires
+ the OpenSSL package to be installed. The "DIRECTORY" argument
+ specifies the root directory of the OpenSSL installation; the
+ default is "/usr/local/ssl".
+
+ "configure" will check for the required header files and libraries
+ to make sure that your OpenSSL installation is sufficient before
+ proceeding.
+
+ --with-pam
+
+ Build with PAM (Pluggable Authentication Modules) support.
+
+ --enable-syslog
+
+ Enables the PostgreSQL server to use the syslog logging facility.
+ (Using this option does not mean that you must log with syslog or
+ even that it will be done by default, it simply makes it possible
+ to turn that option on at run time.)
+
+ --enable-debug
+
+ 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.
+
+ --enable-cassert
+
+ 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.
+
+ --enable-depend
+
+ 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 or C++ compiler different from the one "configure"
+ picks then you can set the environment variables CC or CXX,
+ respectively, to the program of your choice. Similarly, you can
+ override the default compiler flags with the CFLAGS and CXXFLAGS
+ variables. For example:
+
+ env CC=/opt/bin/gcc CFLAGS='-O2 -pipe' ./configure
+
+ 2. 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.
+
+ 3. Regression Tests
+
+ 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.) It is
+ possible that some tests fail, due to differences in error message
+ wording or floating point results. The file "src/test/regress/README"
+ and the Administrator's Guide contain detailed information about
+ interpreting the test results. You can repeat this test at any later
+ time by issuing the same command.
+
+ 4. Installing The Files
+
+ Note: 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 the Section called If You Are Upgrading
+ above.
+
+ To install PostgreSQL enter
+
+ gmake install
+
+ This will install files into the directories that were specified in
+ step 1. 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.
+
+ 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
+
+ gmake -C src/interfaces/perl5 install
+ gmake -C src/interfaces/python install
+
+ 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.
+
+ 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 PostgreSQL include tree
+ into your target include directory. To do that, enter
+
+ gmake install-all-headers
+
+ 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.)
+
+ 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
+
+ To undo the installation use the command "gmake uninstall". However,
+ this will not remove any created directories.
+
+After the installation you can make room by removing the built files from
+the source tree with the "gmake clean" command. This will preserve the files
+made by the configure program, so that you can rebuild everything with
+"gmake" later on. To reset the source tree to the state in which it was
+distributed, use "gmake distclean". If you are going to build for several
+platforms from the same source tree you must do this and re-configure for
+each build.
+
+If you perform a build and then discover that your configure options were
+wrong, or if you change anything that configure investigates (for example,
+you install GNU Readline), then it's a good idea to do "gmake distclean"
+before reconfiguring and rebuilding. Without this, your changes in
+configuration choices may not propagate everywhere they need to.
+
+ ------------------------------------------------------------------------
+
+Post-Installation Setup
+
+Shared Libraries
+
+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 "--libdir" to in step 1.
+You should put these commands into a shell start-up file such as
+"/etc/profile" or "~/.bash_profile". Some good information about the caveats
+associated with this method can be found at
+http://www.visi.com/~barr/ldpath.html.
+
+On some systems it might be preferable to set the environment variable
+LD_RUN_PATH *before* building.
+
+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.
+
+If you are on BSD/OS, Linux, or SunOS 4 and you have root access you can run
+
+/sbin/ldconfig /usr/local/pgsql/lib
+
+(or equivalent directory) after installation to enable the run-time linker
+to find the shared libraries faster. Refer to the manual page of "ldconfig"
+for more information. On FreeBSD, NetBSD, and OpenBSD the command is
+
+/sbin/ldconfig -m /usr/local/pgsql/lib
+
+instead. Other systems are not known to have an equivalent command.
+
+ ------------------------------------------------------------------------
+
+Environment Variables
+
+If you installed into "/usr/local/pgsql" or some other location that is not
+searched for programs by default, you need to add "/usr/local/pgsql/bin" (or
+whatever you set "--bindir" to in step 1) into your PATH. 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
+
+If you are using "csh" or "tcsh", then use this command:
+
+set path = ( /usr/local/pgsql/bin $path )
+
+To enable your system to find the man documentation, you need to add a line
+like the following to a shell start-up file:
+
+MANPATH=/usr/local/pgsql/man:$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 Administrator's Guide contains more information.
+
+ 1. 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
+
+ 2. 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 "-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 "initdb", as illustrated here.
+
+ 3. 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 "-i" option to "postmaster".
+
+ 4. 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 Tutorial 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 the Administrator's Guide, 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 Administrator's Guide.
+
+ * 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 Administrator's Guide.
+
+ ------------------------------------------------------------------------
+
+Supported Platforms
+
+PostgreSQL has been verified by the developer community to work on the
+platforms listed below. A supported platform generally means that PostgreSQL
+builds and installs according to these instructions and that the regression
+tests pass.
+
+ Note: If you are having problems with the installation on a
+ supported platform, please write to <pgsql-bugs@postgresql.org> or
+ <pgsql-ports@postgresql.org>, not to the people listed here.
+
+ OS Processor Version Reported Remarks
+ AIX RS6000 7.2 2001-12-19, Andreas Zeugswetter see also
+ (<ZeugswetterA@spardat.at>), doc/FAQ_AIX
+ Tatsuo Ishii
+ (<t-ishii@sra.co.jp>)
+ BeOS x86 7.2 2001-11-29, Cyril Velter 5.0.4
+ (<cyril.velter@libertysurf.fr>)
+ BSD/OS x86 7.2 2001-11-27, Bruce Momjian 4.2
+ (<pgman@candle.pha.pa.us>)
+ FreeBSDAlpha 7.2 2001-12-18, Chris Kings-Lynne
+ (<chriskl@familyhealth.com.au>)
+ FreeBSDx86 7.2 2001-11-14, Chris Kings-Lynne
+ (<chriskl@familyhealth.com.au>)
+ HP-UX PA-RISC 7.2 2001-11-29, Joseph Conway 11.00 and 10.20;
+ (<Joseph.Conway@home.com>), Tom see also
+ Lane (<tgl@sss.pgh.pa.us>) doc/FAQ_HPUX
+ IRIX MIPS 7.2 2001-11-28, Luis Amigo 6.5.13, MIPSPro
+ (<lamigo@atc.unican.es>) 7.30
+ Linux Alpha 7.2 2001-11-16, Tom Lane 2.2.18; tested at
+ (<tgl@sss.pgh.pa.us>) SourceForge
+ Linux armv4l 7.2 2001-12-10, Mark Knox 2.2.x
+ (<segfault@hardline.org>)
+ Linux MIPS 7.2 2001-11-15, Hisao Shibuya 2.0.x; Cobalt
+ (<shibuya@alpha.or.jp>) Qube2
+ Linux PlayStation 7.2 2001-12-12, Permaine Cheung #undef
+ 2 <pcheung@redhat.com>) HAS_TEST_AND_SET,
+ slock_t
+ Linux PPC74xx 7.2 2001-11-16, Tom Lane 2.2.18; Apple G3
+ (<tgl@sss.pgh.pa.us>)
+ Linux S/390 7.2 2001-12-12, Permaine Cheung
+ <pcheung@redhat.com>)
+ Linux Sparc 7.2 2001-11-28, Doug McNaught 2.2.19
+ (<doug@wireboard.com>)
+ Linux x86 7.2 2001-11-15, Thomas Lockhart 2.0.x, 2.2.x,
+ (<lockhart@fourpalms.org>) 2.4.x
+ MacOS XPPC 7.2 2001-11-28, Gavin Sherry 10.1.x
+ (<swm@linuxworld.com.au>)
+ NetBSD Alpha 7.2 2001-11-20, Thomas Thai 1.5W
+ (<tom@minnesota.com>)
+ NetBSD arm32 7.1 2001-03-21, Patrick Welche 1.5E
+ (<prlw1@cam.ac.uk>)
+ NetBSD m68k 7.0 2000-04-10, Henry B. Hotz Mac 8xx
+ (<hotz@jpl.nasa.gov>)
+ NetBSD PPC 7.2 2001-11-28, Bill Studenmund 1.5
+ (<wrstuden@netbsd.org>)
+ NetBSD Sparc 7.2 2001-12-03, Matthew Green 32- and 64-bit
+ (<mrg@eterna.com.au>) builds
+ NetBSD VAX 7.1 2001-03-30, Tom I. Helbekkmo 1.5
+ (<tih@kpnQwest.no>)
+ NetBSD x86 7.2 2001-11-28, Bill Studenmund 1.5
+ (<wrstuden@netbsd.org>)
+ OpenBSDSparc 7.2 2001-11-27, Brandon Palmer 3.0
+ (<bpalmer@crimelabs.net>)
+ OpenBSDx86 7.2 2001-11-26, Brandon Palmer 3.0
+ (<bpalmer@crimelabs.net>)
+ Open x86 7.2 2001-11-28, OU-8 Larry Rosenman see also
+ UNIX (<ler@lerctr.org>), UW-7 Olivier doc/FAQ_SCO
+ Prenant (<ohp@pyrenet.fr>)
+ QNX 4 x86 7.2 2001-12-10, Bernd Tegge 4.25; see also
+ RTOS (<tegge@repas-aeg.de>) doc/FAQ_QNX4
+ SolarisSparc 7.2 2001-11-12, Andrew Sullivan 2.6-8; see also
+ (<andrew@libertyrms.com>) doc/FAQ_Solaris
+ Solarisx86 7.2 2001-11-28, Martin Renters 2.8; see also
+ (<martin@datafax.com>) doc/FAQ_Solaris
+ SunOS 4Sparc 7.2 2001-12-04, Tatsuo Ishii
+ (<t-ishii@sra.co.jp>)
+ Tru64 Alpha 7.2 2001-11-26, Alessio Bragadini 5.0; 4.0g with cc
+ UNIX (<alessio@albourne.com>), Bernd and gcc
+ Tegge (<tegge@repas-aeg.de>)
+ Windowsx86 7.2 2001-12-13, Dave Page with Cygwin; see
+ (<dpage@vale-housing.co.uk>), doc/FAQ_MSWIN
+ Jason Tishler
+ (<jason@tishler.net>)
+ Windowsx86 7.2 2001-12-10, Dave Page native is
+ (<dpage@vale-housing.co.uk>) client-side only;
+ see
+ Administrator's
+ Guide
+
+Unsupported Platforms: The following platforms are either known not to work,
+or they used to work in a previous release and we did not receive explicit
+confirmation of a successful test with version 7.2 at the time this list was
+compiled. We include these here to let you know that these platforms *could*
+be supported if given some attention.
+
+ OS Processor Version Reported Remarks
+ DG/UX m88k 6.3 1998-03-01, Brian E Gallew no recent
+ 5.4R4.11 (<geek+@cmu.edu>) reports
+ MkLinux DR1PPC750 7.0 2001-04-03, Tatsuo Ishii 7.1 needs OS
+ (<t-ishii@sra.co.jp>) update?
+ NeXTSTEP x86 6.x 1998-03-01, David Wetzel bit rot
+ (<dave@turbocat.de>) suspected
+ QNX RTOS v6x86 7.2 2001-11-20, Igor Kovalenko patches
+ (<Igor.Kovalenko@motorola.com>) available in
+ archives,
+ but too late
+ for 7.2
+ SCO x86 6.5 1999-05-25, Andrew Merrill 7.2 should
+ OpenServer (<andrew@compclass.com>) work, but no
+ 5 reports; see
+ also
+ doc/FAQ_SCO
+ System V R4m88k 6.2.1 1998-03-01, Doug Winterburn needs new
+ (<dlw@seavme.xroads.com>) TAS spinlock
+ code
+ System V R4MIPS 6.4 1998-10-28, Frank Ridderbusch no recent
+ (<ridderbusch.pad@sni.de>) reports
+ Ultrix MIPS 7.1 2001-03-26 TAS spinlock
+ code not
+ detected
+ Ultrix VAX 6.x 1998-03-01
projects / postgresql / blobdiff