postgres/INSTALL

PostgreSQL Installation Guide
by The PostgreSQL Development Team
Edited by Thomas Lockhart

PostgreSQL is <20> 1996-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                         

List of Tables

       2-1. Supported Platforms                           
       2-2. Possibly Incompatible Platforms               
       4-1. Kerberos Parameter Examples                   

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. Needs new 
       5.4R4.11                                       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.5       1999-05-24  (Thomas Lockhart 
       2.0.x/glibc                                    (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 (Tatsuo Ishii
       2.1.24                                         (mailto:t-ishii@sra.co.jp))
       mklinux DR3 PPC750      v6.4       1998-09-16  PowerMac 7600 (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 in date/time 
       current                                        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 (Tatsuo Ishii
       4.1.4                                          (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
           
        

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 
         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/ghostscript/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

       # documentation

       HSTYLE= /home/lockhart/SGML/db118.d/docbook/html
       PSTYLE= /home/lockhart/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.Berkel-
                                     ey.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. 
        
        Documentation
          New and updated material is present throughout the
         documentation. New FAQs have been contributed for SGI
         and AIX platforms. The Tutorial has introductory
         information on SQL from Stefan Simkovics. For the User's
         Guide, there are reference pages covering the postmaster
         and more utility programs, and a new appendix contains
         details on date/time behavior. The Administrator's Guide
         has a new chapter on troubleshooting from Tom Lane. And
         the Programmer's Guide has a description of query
         processing, also from Stefan, and details on obtaining
         the Postgres source tree via anonymous CVS and CVSup.


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)