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.1 Migration to v6.5.1 Detailed Change List 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.1 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.1, 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.1. 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 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.1.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 from 6.5, you do not need to dump/reload or initdb. Simply compile the source code, stop the postmaster, do a "make install", and restart the postmaster. If you are upgrading from 6.4.* or earlier, 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.1.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.1.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 $ nohup postmaster -i > pgserver.log 2>&1 & 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 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)