
                    PostgreSQL Installation Guide
                   The PostgreSQL Development Team
                                  
                              Edited by
                           Thomas Lockhart

PostgreSQL is Copyright  1996-2000 by PostgreSQL Inc.

Table of Contents

      Summary                                                    
      1. Introduction                                            
      2. Ports                                                   
          Currently Supported Platforms                          
          Unsupported Platforms                                  
      3. Installation                                            
          Before you start                                       
          Installation Procedure                                 
      4. Configuration Options                                   
      5. Release Notes                                           
          Release 7.0                                            
             Migration to v7.0                                   
             Detailed Change List                                
      6. Regression Test                                         

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 an 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 7.0 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      RS6000    v7.0    2000-04-05  Andreas Zeugswetter 
      4.3.2                                  (Andreas.Zeugswetter@telecom.at)
      BSDI     x86       v7.0    2000-04-04  Bruce Momjian 
      4.01                                   (maillist@candle.pha.pa.us)
      Compaq   Alpha     v7.0    2000-04-11  Andrew McMurry 
      Tru64                                  (andrew.mcmurry@astro.uio.no)
      FreeBSD  x86       v7.0    2000-04-04  Marc Fournier 
      4.0                                    (scrappy@hub.org)
      HPUX     PA-RISC   v7.0    2000-04-12  Both 9.0x and 10.20. Tom Lane 
                                             (tgl@sss.pgh.pa.us)
      IRIX     MIPS      v6.5.3  2000-02-18  MIPSPro 7.3.1.1m N32 build. Kevin 
      6.5.6f                                 Wheatley (hxpro@cinesite.co.uk)
      Linux    Alpha     v7.0    2000-04-05  With published patches.
      2.0.x                                  Ryan Kirkpatrick 
                                             (pgsql@rkirkpat.net)
      Linux    armv4l    v7.0    2000-04-17  Regression test needs work.
      2.2.x                                  Mark Knox 
                                             (segfault@hardline.org)
      Linux    x86       v7.0    2000-03-26  Lamar Owens 
      2.2.x                                  (lamar.owen@wgcr.org)
      Linux    MIPS      v7.0    2000-04-13  Cobalt Qube. Tatsuo Ishii 
      2.0.x                                  (t-ishii@sra.co.jp)
      Linux    Sparc     v7.0    2000-04-02  Tom Szybist 
      2.2.5                                  (szybist@boxhill.com)
      Linux    PPC603e   v7.0    2000-04-13  Tatsuo Ishii 
      PPC R4                                 (t-ishii@sra.co.jp)
      mklinux  PPC750    v7.0    2000-04-13  Tatsuo Ishii 
                                             (t-ishii@sra.co.jp)
      NetBSD   arm32     v7.0    2000-04-08  Patrick Welche 
      1.4                                    (prlw1@newn.cam.ac.uk)
      NetBSD   x86       v7.0    2000-03-26  Patrick Welche 
      1.4U                                   (prlw1@newn.cam.ac.uk)
      NetBSD   m68k      v7.0    2000-04-10  Mac 8xx. Henry B. Hotz 
                                             (hotz@jpl.nasa.gov)
      NetBSD-  Sparc     v7.0    2000-04-13  Tom I Helbekkmo 
      /sparc                                 (tih@kpnQwest.no)
      QNX      x86       v7.0    2000-04-01  Dr. Andreas Kardos 
      4.25                                   (kardos@repas-aeg.de)
      SCO Open x86       v6.5    1999-05-25  Andrew Merrill 
      Server 5                               (andrew@compclass.com)
      SCO UW7  x86       v7.0    2000-04-18  See FAQ. Billy G. Allie 
                                             (Bill.Allie@mug.org)
      Solaris  x86       v7.0    2000-04-12  Marc Fournier 
                                             (scrappy@hub.org)
      Solaris  Sparc     v7.0    2000-04-12  Peter Eisentraut 
      2.5-.7                                 (peter_e@gmx.net)
      SunOS    Sparc     v7.0    2000-04-13  Tatsuo Ishii 
      4.1.4                                  (t-ishii@sra.co.jp)
      Windows  x86       v7.0    2000-04-02  No server-side. Magnus Hagander 
      Win32                                  (mha@sollentuna.net)
      WinNT    x86       v7.0    2000-03-30  Uses Cygwin library. Daniel Horak 
      Cygwin                                 (horak@sit.plzen-city.cz) 


       

         Note: For Windows NT, the server-side port of Postgres uses 
         the RedHat/Cygnus Cygwin library and toolset. For Windows 
         9x, no server-side port is available due to OS limitations.

Unsupported Platforms


       Platforms listed for v6.3.x-v6.5.x should also work with v7.0, 
      but we did not receive explicit confirmation of such at the 
      time this list was compiled. We include these here to let you 
      know that these platforms could be supported if given some 
      attention. 
       At the time of publication, the following platforms have not 
      been tested for v7.0 or v6.5.x: 

      Table 2-2. Unsupported Platforms
      OS       Processor Version  Reported   Remarks
      BeOS     x86       v7.0     2000-05-01 Client-side coming soon?
                                             Adam Haberlach 
                                             (adam@newsnipple.com)
      DGUX     m88k      v6.3     1998-03-01 v6.4 probably OK. Needs new 
      5.4R4.11                               maintainer. Brian E Gallew 
                                             (geek+@cmu.edu)
      NetBSD   NS32532   v6.4     1998-10-27 Date/time math annoyances.
      current                                Jon Buller (jonb@metronet.com)
      NetBSD   VAX       v6.3     1998-03-01 v7.0 should work. Tom I Helbekkmo 
      1.3                                    (tih@kpnQwest.no)
      SVR4 4.4 m88k      v6.2.1   1998-03-01 v6.4.x will need TAS spinlock 
                                             code. Doug Winterburn 
                                             (dlw@seavme.xroads.com)
      SVR4     MIPS      v6.4     1998-10-28 No 64-bit int. Frank Ridderbusch 
                                             (ridderbusch.pad@sni.de)
      Ultrix   MIPS, VAX v6.x     1998-03-01 No recent reports; obsolete?


       
       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-3. Incompatible Platforms
      OS       Processor Version  Reported    Remarks
      MacOS    all       v6.x     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 
                                              (dave@turbocat.de)


       
Chapter 3. Installation


       Installation instructions for PostgreSQL 7.0. 

       If you haven't gotten the PostgreSQL distribution, get it from 
      ftp.postgresql.org (ftp://ftp.postgresql.org), then unpack it: 

      > gunzip postgresql-7.0.tar.gz
      > tar -xf postgresql-7.0.tar
      > mv postgresql-7.0 /usr/src
         

       

Before you start


       Building PostgreSQL requires GNU make. It will not work with 
      other make programs. On GNU/Linux systems GNU make is the 
      default tool, on other systems you may find that GNU make is 
      installed under the name gmake. We will use that name from now 
      on to indicate GNU make, no matter what name it has on your 
      system. To test for GNU make enter 

      > gmake --version
          

       If you need to get GNU make, you can find it at 
      ftp://ftp.gnu.org. 
       Up to date information on supported platforms is at 
      http://www.postgresql.org/docs/admin/ports.htm 
      (http://www.postgresql.org/docs/admin/ports.htm). In general, 
      most Unix-compatible platforms with modern libraries should be 
      able to run PostgreSQL. In the doc subdirectory of the 
      distribution are several platform-specific FAQ and README 
      documents you might wish to consult if you are having trouble. 
       Although the minimum required memory for running PostgreSQL 
      can be as little as 8MB, there are noticeable speed 
      improvements when expanding memory up to 96MB or beyond. The 
      rule is you can never have too much memory. 
       Check that you have sufficient disk space. You will need about 
      30 Mbytes for the source tree during compilation and about 5 
      Mbytes for the installation directory. An empty database takes 
      about 1 Mbyte, otherwise they take about five times the amount 
      of space that a flat text file with the same data would take. 
      If you run the regression tests you will temporarily need an 
      extra 20MB. 
       To check for disk space, use 

      > df -k

       
       Considering today's prices for hard disks, getting a large and 
      fast hard disk should probably be in your plans before putting 
      a database into production use. 

Installation Procedure


      PostgreSQL Installation
       For a fresh install or upgrading from previous releases of 
      PostgreSQL: 
      1.  Create the PostgreSQL superuser account. This is the user 
         the server will run as. For production use you should create 
         a separate, unprivileged account (postgres is commonly 
         used). If you do not have root access or just want to play 
         around, your own user account is enough. 
          Running PostgreSQL as root, bin, or any other account with 
         special access rights is a security risk; don't do it. The 
         postmaster will in fact refuse to start as root. 
          You need not do the building and installation itself under 
         this account (although you can). You will be told when you 
         need to login as the database superuser. 
      2.  Configure the source code for your system. It is this step 
         at which you can specify your actual installation path for 
         the build process and make choices about what gets 
         installed. Change into the src subdirectory and type: 
         > ./configure
               
          followed by any options you might want to give it. For a 
         first installation you should be able to do fine without 
         any. For a complete list of options, type: 
         > ./configure --help
               
          Some of the more commonly used ones are: 

         --prefix=BASEDIR
            Selects a different base directory for the installation 
           of PostgreSQL. The default is /usr/local/pgsql. 

         --enable-locale
            If you want to use locales. 

         --enable-multibyte
            Allows the use of multibyte character encodings. This is 
           primarily for languages like Japanese, Korean, or Chinese. 

         --with-perl
            Builds the Perl interface and plperl extension language. 
           Please note that the Perl interface needs to be installed 
           into the usual place for Perl modules (typically under 
           /usr/lib/perl), so you must have root access to perform 
           the installation step. (It is often easiest to leave out 
           --with-perl initially, and then build and install the Perl 
           interface after completing the installation of PostgreSQL 
           itself.) 

         --with-odbc
            Builds the ODBC driver package. 

         --with-tcl
            Builds interface libraries and programs requiring Tcl/Tk, 
           including libpgtcl, pgtclsh, and pgtksh. 
          
      3.  Compile the program. Type 
         > gmake
               
          The compilation process can take anywhere from 10 minutes 
         to an hour. Your mileage will most certainly vary. Remember 
         to use GNU make. 
          The last line displayed will hopefully be 
         All of PostgreSQL is successfully made. Ready to install.
               
          
      4.  If you want to test the newly built server before you 
         install it, you can run the regression tests at this point. 
         The regression tests are a test suite to verify that 
         PostgreSQL runs on your machine in the way the developers 
         expected it to. For detailed instructions see Regression 
         Test. (Be sure to use the "parallel regress test" method, 
         since the sequential method only works with an 
         already-installed server.) 
      5.  If you are not upgrading an existing system then skip to 
         step 7. 
          You now need to back up your existing database. To dump 
         your fairly recent post-6.0 database installation, type 
         > pg_dumpall > db.out
               
          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. 
          Make sure to use the pg_dumpall command from the version 
         you are currently running. 7.0's pg_dumpall will not work on 
         older databases. However, if you are still using 6.0, do not 
         use the pg_dumpall script from 6.0 or everything will be 
         owned by the PostgreSQL superuser after you reload. In that 
         case you should grab pg_dumpall from a later 6.x.x release. 
         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. 

                                     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. 



      6.  If you are upgrading an existing system then kill the 
         database server now. Type 
         > ps ax | grep postmaster
               
          or 
         > ps -e | grep postmaster
               
          (It depends on your system which one of these two works. No 
         harm can be done by typing the wrong one.) This should list 
         the process numbers for a number of processes, similar to 
         this: 
           263  ?  SW   0:00 (postmaster)
           777  p1 S    0:00 grep postmaster
               
          Type the following line, with pid replaced by the process 
         id for process postmaster (263 in the above case). (Do not 
         use the id for the process "grep postmaster".) 
         > kill pid
               
          

           Tip: On systems which have PostgreSQL started at boot 
           time, there is probably a startup file that will 
           accomplish the same thing. For example, on a Redhat Linux 
           system one might find that 
           > /etc/rc.d/init.d/postgres.init stop
                  
            works.

          Also move the old directories out of the way. Type the 
         following: 
         > mv /usr/local/pgsql /usr/local/pgsql.old
               
          (substitute your particular paths). 
      7.  Install the PostgreSQL executable files and libraries. Type 
         > gmake install
               
          
          You should do this step as the user that you want the 
         installed executables to be owned by. This does not have to 
         be the same as the database superuser; some people prefer to 
         have the installed files be owned by root. 
      8.  If necessary, tell your system how to find the new shared 
         libraries. How to do this varies between platforms. The most 
         widely usable method is to set the environment variable 
         LD_LIBRARY_PATH: 
         > LD_LIBRARY_PATH=/usr/local/pgsql/lib
         > export LD_LIBRARY_PATH
               
          on sh, ksh, bash, zsh or 
         > setenv LD_LIBRARY_PATH /usr/local/pgsql/lib
               
          on csh or tcsh. You might want to put this into a shell 
         startup file such as /etc/profile. 
          On some systems the following is the preferred method, but 
         you must have root access. Edit file /etc/ld.so.conf to add 
         a line 
         /usr/local/pgsql/lib
               
          Then run command /sbin/ldconfig. 
          If in doubt, refer to the manual pages of your system. If 
         you later on get a message like 
         psql: error in loading shared libraries
         libpq.so.2.1: cannot open shared object file: No such file 
         or directory
               
          then the above was necessary. Simply do this step then. 
      9.  Create the database installation (the working data files). 
         To do this you must log in to your PostgreSQL superuser 
         account. It will not work as root. 
         > mkdir /usr/local/pgsql/data
         > chown postgres /usr/local/pgsql/data
         > su - postgres
         > /usr/local/pgsql/bin/initdb -D /usr/local/pgsql/data
               
          
          The -D option specifies the location where the data will be 
         stored. You can use any path you want, it does not have to 
         be under the installation directory. Just make sure that the 
         superuser account can write to the directory (or create it, 
         if it doesn't already exist) before starting initdb. (If you 
         have already been doing the installation up to now as the 
         PostgreSQL superuser, you may have to log in as root 
         temporarily to create the data directory underneath a 
         root-owned directory.) 
      10.      The previous step should have told you how to start up 
         the database server. Do so now. The command should look 
         something like 
         > /usr/local/pgsql/bin/postmaster -D /usr/local/pgsql/data
               
          This will start the server in the foreground. To make it 
         detach to the background, you can use the -S option, but 
         then you won't see any log messages the server produces. A 
         better way to put the server in the background is 
         > nohup /usr/local/pgsql/bin/postmaster -D 
         /usr/local/pgsql/data \
             </dev/null >>server.log 2>>1 &
               
          
      11.      If you are upgrading from an existing installation, 
         dump your data back in: 
         > /usr/local/pgsql/bin/psql -d template1 -f db.out
               
          You also might want to copy over the old pg_hba.conf file 
         and any other files you might have had set up for 
         authentication, such as password files. 

       This concludes the installation proper. To make your life more 
      productive and enjoyable you should look at the following 
      optional steps and suggestions. 
      o   Life will be more convenient if you set up some environment 
        variables. First of all you probably want to include 
        /usr/local/pgsql/bin (or equivalent) into your PATH. To do 
        this, add the following to your shell startup file, such as 
        ~/.bash_profile (or /etc/profile, if you want it to affect 
        every user): 
        > PATH=$PATH:/usr/local/pgsql/bin
              
         
         Furthermore, if you set PGDATA in the environment of the 
        PostgreSQL superuser, you can omit the -D for postmaster and 
        initdb. 
      o   You probably want to install the man and HTML documentation. 
        Type 
        > cd /usr/src/pgsql/postgresql-7.0/doc
        > gmake install
              
         This will install files under /usr/local/pgsql/doc and 
        /usr/local/pgsql/man. To enable your system to find the man 
        documentation, you need to add a line like the following to a 
        shell startup file: 
        > MANPATH=$MANPATH:/usr/local/pgsql/man
              
         
         The documentation is also available in Postscript format. If 
        you have a Postscript printer, or have your machine already 
        set up to accept Postscript files using a print filter, then 
        to print the User's Guide simply type 
        > cd /usr/local/pgsql/doc
        > gunzip -c 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. 
        > gunzip -c user.ps.gz \
            | gs -sDEVICE=laserjet -r300 -q -dNOPAUSE -sOutputFile=- 
        \
            | lpr
              
         Printer setups can vary wildly from system to system. If in 
        doubt, consult your manuals or your local expert. 
         The Adminstrator's Guide should probably be your first 
        reading if you are completely new to PostgreSQL, as it 
        contains information about how to set up database users and 
        authentication. 
      o   Usually, you will want to modify your computer so that it 
        will automatically start the database server whenever it 
        boots. This is not required; the PostgreSQL server can be run 
        successfully from non-privileged accounts without root 
        intervention. 
         Different systems have different conventions for starting up 
        daemons at boot time, so you are advised to familiarize 
        yourself with them. Most systems have a file /etc/rc.local or 
        /etc/rc.d/rc.local which is almost certainly no bad place to 
        put such a command. Whatever you do, postmaster must be run 
        by the PostgreSQL superuser (postgres) and not by root or any 
        other user. Therefore you probably always want to form your 
        command lines along the lines of su -c '...' postgres. 
         It might be advisable to keep a log of the server output. To 
        start the server that way try: 
        > nohup su -c 'postmaster -D /usr/local/pgsql/data > 
        server.log 2>&1' postgres &
              
         
         Here are a few more operating system specific suggestions. 
        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   Run the regression tests against the installed server (using 
        the sequential test method). If you didn't run the tests 
        before installation, you should definitely do it now. For 
        detailed instructions see Regression Test. 
       To start experimenting with Postgres, set up the paths as 
      explained above and start the server. To create a database, 
      type 

      > createdb testdb
          

       Then enter 

      > psql testdb
          

       to connect to that database. At the prompt you can enter SQL 
      commands and start experimenting. 
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: 

      Directories to install PostgreSQL in:
        --prefix=PREFIX         install architecture-independent files
                                [/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
        --enable-FEATURE[=ARG]  include FEATURE [ARG=yes]
        --with-PACKAGE[=ARG]    use PACKAGE [ARG=yes]
        --without-PACKAGE       do not use PACKAGE
      --enable and --with options recognized:
        --with-template=template
                                use operating system template file
                                    see template directory
        --with-includes=dirs    look for header files for tcl/tk, etc 
        --with-libraries=dirs   look for additional libraries in DIRS
        --with-libs=dirs        alternate for --with-libraries
        --enable-locale         enable locale support
        --enable-recode         enable cyrillic recode support
        --enable-multibyte      enable multibyte character support
        --with-pgport=portnum   change default postmaster port
        --with-maxbackends=n    set default maximum number of processes 
        --with-tcl              build Tcl interfaces and pgtclsh
        --with-tclconfig=tcldir
                                tclConfig.sh and tkConfig.sh location
        --with-perl             build Perl interface and plperl
        --with-odbc             build ODBC driver package
        --with-odbcinst=odbcdir
                                default directory for odbcinst.ini
        --enable-cassert        enable assertion checks
        --enable-debug          build with debugging symbols (-g) 
        --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++. 
       Use the --with-includes and --with-libraries options if you 
      want to build Postgres using include files or libraries that 
      are not installed in your system's standard search path. For 
      example, you might use these to build with an experimental 
      version of Tcl. If you need to specify more than one 
      nonstandard directory for include files or libraries, do it 
      like this: 

      --with-includes="/opt/tcl/include /opt/perl5/include"
          

       

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. 
       Alternatively, you can set variables on the make command line: 

      make [ variable=value [...] ]
          

       
       A few of the many variables that 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 1999-06-01

      POSTGRESDIR= /opt/postgres/current
      CFLAGS+= -m486 -O2

      # 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
        Param-     Example 
       eter 
        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 7.0


       This release contains improvements in many areas, 
      demonstrating the continued growth of PostgreSQL. There are 
      more improvements and fixes in 7.0 than in any previous 
      release. The developers have confidence that this is the best 
      release yet; we do our best to put out only solid releases, and 
      this one is no exception. 
       Major changes in this release: 

       Foreign Keys 
          Foreign keys are now implemented, with the exception of 
         PARTIAL MATCH foreign keys. Many users have been asking for 
         this feature, and we are pleased to offer it. 

       Optimizer Overhaul 
          Continuing on work started a year ago, the optimizer has 
         been improved, allowing better query plan selection and 
         faster performance with less memory usage. 

       Updated psql 
          psql, our interactive terminal monitor, has been updated 
         with a variety of new features. See the psql manual page for 
         details. 

       Join Syntax 
          SQL92 join syntax is now supported, though only as INNER 
         JOINs for this release. JOIN, NATURAL JOIN, JOIN/USING, 
         JOIN/ON are available, as are column correlation names. 
       

Migration to v7.0


       A dump/restore using pg_dump is required for those wishing to 
      migrate data from any previous release of Postgres. For those 
      upgrading from 6.5.*, you may instead use pg_upgrade to upgrade 
      to this release; however, a full dump/reload installation is 
      always the most robust method for upgrades. 
       Interface and compatibility issues to consider for the new 
      release include: 
      o   The date/time types datetime and timespan have been 
        superceded by the SQL92-defined types timestamp and interval. 
        Although there has been some effort to ease the transition by 
        allowing Postgres to recognize the deprecated type names and 
        translate them to the new type names, this mechanism may not 
        be completely transparent to your existing application. 
      o   The optimizer has been substantially improved in the area of 
        query cost estimation. In some cases, this will result in 
        decreased query times as the optimizer makes a better choice 
        for the preferred plan. However, in a small number of cases, 
        usually involving pathological distributions of data, your 
        query times may go up. If you are dealing with large amounts 
        of data, you may want to check your queries to verify 
        performance. 
      o   The JDBC and ODBC interfaces have been upgraded and 
        extended. 
      o   The string function CHAR_LENGTH is now a native function. 
        Previous versions translated this into a call to LENGTH, 
        which could result in ambiguity with other types implementing 
        LENGTH such as the geometric types. 
       

Detailed Change List


       

   Bug Fixes
   ---------
   Prevent function calls exceeding maximum number of arguments (Tom)
   Improve CASE construct (Tom)
   Fix SELECT coalesce(f1,0) FROM int4_tbl GROUP BY f1 (Tom)
   Fix SELECT sentence.words[0] FROM sentence GROUP BY 
    sentence.words[0] (Tom)
   Fix GROUP BY scan bug (Tom)
   Improvements in SQL grammar processing (Tom)
   Fix for views involved in INSERT ... SELECT ... (Tom)
   Fix for SELECT a/2, a/2 FROM missing_target GROUP BY a/2 (Tom)
   Fix for subselects in INSERT ... SELECT (Tom)
   Prevent INSERT ... SELECT ... ORDER BY (Tom)
   Fixes for relations greater than 2GB, including vacuum
   Improve propagating system table changes to other backends (Tom)
   Improve propagating user table changes to other backends (Tom)
   Fix handling of temp tables in complex situations (Bruce, Tom)
   Allow table locking at table open, improving concurrent 
    reliability (Tom)
   Properly quote sequence names in pg_dump (Ross J. Reedstrom)
   Prevent DROP DATABASE while others accessing
   Prevent any rows from being returned by GROUP BY if no rows 
    processed (Tom)
   Fix SELECT COUNT(1) FROM table WHERE ...' if no rows matching 
    WHERE (Tom)
   Fix pg_upgrade so it works for MVCC (Tom)
   Fix for SELECT ... WHERE x IN (SELECT ... HAVING SUM(x) > 1) (Tom)
   Fix for "f1 datetime DEFAULT 'now'"  (Tom)
   Fix problems with CURRENT_DATE used in DEFAULT (Tom)
   Allow comment-only lines, and ;;; lines too. (Tom)
   Improve recovery after failed disk writes, disk full (Hiroshi)
   Fix cases where table is mentioned in FROM but not joined (Tom)
   Allow HAVING clause without aggregate functions (Tom)
   Fix for "--" comment and no trailing newline, as seen in perl
   Improve pg_dump failure error reports (Bruce)
   Allow sorts and hashes to exceed 2GB file sizes (Tom)
   Fix for pg_dump dumping of inherited rules (Tom)
   Fix for NULL handling comparisons (Tom)
   Fix inconsistent state caused by failed CREATE/DROP (Hiroshi)
   Fix for dbname with dash
   Prevent DROP INDEX from interfering with other backends (Tom)
   Fix file descriptor leak in verify_password()
   Fix for "Unable to identify an operator =$" problem
   Fix ODBC so no segfault if CommLog and Debug enabled
    (Dirk Niggemann)
   Fix for recursive exit call (Massimo)
   Fix for extra-long timezones (Jeroen van Vianen)
   Make pg_dump preserve primary key information (Peter E)
   Prevent databases with single quotes (Peter E)
   Prevent DROP DATABASE inside  transaction (Peter E)
   ecpg memory leak fixes (Stephen Birch)
   Fix for SELECT null::text, SELECT int4fac(null)
    and SELECT 2 + (null) (Tom)
   Y2K timestamp fix (Massimo)
   Fix for VACUUM 'HEAP_MOVED_IN was not expected' errors (Tom)
   Fix for views with tables/columns containing spaces  (Tom)
   Prevent permissions on indexes (Peter E)
   Fix for spinlock stuck problem on error (Hiroshi)
   Fix ipcclean on Linux
   Fix handling of NULL constraint conditions (Tom)
   Fix memory leak in odbc driver (Nick Gorham)
   Fix for permission check on UNION tables (Tom)
   Fix to allow SELECT 'a' LIKE 'a' (Tom)
   Fix for SELECT 1 + NULL (Tom)
   Fixes to CHAR
   Fix log() on numeric type (Tom)
   Deprecate ':' and ';' operators
   Allow vacuum of temporary tables
   Disallow inherited columns with the same name as new columns
   Recover or force failure when disk space is exhausted(Hiroshi)
   Fix INSERT INTO ... SELECT with AS columns matching result columns
   Fix INSERT ... SELECT ... GROUP BY groups by target columns not 
    source columns(Tom)
   Fix CREATE TABLE test (a char(5) DEFAULT text '', b int4)
    with INSERT(Tom)
   Fix UNION with LIMIT
   Fix CREATE TABLE x AS SELECT 1 UNION SELECT 2
   Fix CREATE TABLE test(col char(2) DEFAULT user)
   Fix mismatched types in CREATE TABLE ... DEFAULT
   Fix SELECT * FROM pg_class where oid in (0,-1)
   Fix SELECT COUNT('asdf') FROM pg_class WHERE oid=12
   Prevent user who can create databases can modifying pg_database 
    table (Peter E)
   Fix btree to give a useful elog when key > 1/2 (page - overhead)
    (Tom)
   Fix INSERT of 0.0 into DECIMAL(4,4) field (Tom)

   Enhancements
   ------------
   New CLI interface include file sqlcli.h, based on SQL3/SQL98
   Remove all limits on query length, row length limit still 
    exists (Tom)
   Update jdbc protocol to 2.0 (Jens Glaser (jens@jens.de))
   Add TRUNCATE command to quickly truncate relation (Mike Mascari)
   Fix to give super user and createdb user proper update catalog 
    rights (Peter E)
   Allow ecpg bool variables to have NULL values (Christof)
   Issue ecpg error if NULL value for variable with no NULL 
    indicator (Christof)
   Allow ^C to cancel COPY command (Massimo)
   Add SET FSYNC and SHOW PG_OPTIONS commands (Massimo)
   Function name overloading for dynamically-loaded C functions 
    (Frankpitt)
   Add CmdTuples() to libpq++(Vince)
   New CREATE CONSTRAINT TRIGGER and SET CONSTRAINTS commands (Jan)
   Allow CREATE FUNCTION/WITH clause to be used for all types
   configure --enable-debug adds -g (Peter E)
   configure --disable-debug removes -g (Peter E)
   Allow more complex default expressions (Tom)
   First real FOREIGN KEY constraint trigger functionality (Jan)
   Add FOREIGN KEY ... MATCH FULL ... ON DELETE CASCADE (Jan)
   Add FOREIGN KEY ... MATCH <unspecified> referential actions 
    (Don Baccus)
   Allow WHERE restriction on ctid (physical heap location) (Hiroshi)
   Move pginterface from contrib to interface directory,
    rename to pgeasy (Bruce)
   Change pgeasy connectdb() parameter ordering (Bruce)
   Require SELECT DISTINCT target list to have all ORDER BY 
    columns (Tom)
   Add Oracle's COMMENT ON command (Mike Mascari (mascarim@yahoo))
   libpq's PQsetNoticeProcessor function now returns previous 
    hook (Peter E)
   Prevent PQsetNoticeProcessor from being set to NULL (Peter E)
   Make USING in COPY optional (Bruce)
   Allow subselects in the target list (Tom)
   Allow subselects on the left side of comparison operators (Tom)
   New parallel regression test (Jan)
   Change backend-side COPY to write files with permissions 644 
    not 666 (Tom)
   Force permissions on PGDATA directory to be secure, even if it 
    exists (Tom)
   Added psql LASTOID variable to return last inserted oid (Peter E)
   Allow concurrent vacuum and remove pg_vlock vacuum lock file (Tom)
   Add permissions check for vacuum (Peter E)
   New libpq functions to allow asynchronous connections: 
   PQconnectStart(), PQconnectPoll(), PQresetStart(), PQresetPoll(), 
   PQsetenvStart(), PQsetenvPoll(), PQsetenvAbort (Ewan Mellor)
   New libpq PQsetenv() function (Ewan Mellor)
   create/alter user extension (Peter E)
   New postmaster.pid and postmaster.opts under $PGDATA (Tatsuo)
   New scripts for create/drop user/db (Peter E)
   Major psql overhaul (Peter E)
   Add const to libpq interface (Peter E)
   New libpq function PQoidValue (Peter E)
   Show specific non-aggregate causing problem with GROUP BY (Tom)
   Make changes to pg_shadow recreate pg_pwd file (Peter E)
   Add aggregate(DISTINCT ...) (Tom)
   Allow flag to control COPY input/output of NULLs (Peter E)
   Make postgres user have a password by default (Peter E)
   Add CREATE/ALTER/DROP GROUP (Peter E)
   All administration scripts now support --long options
    (Peter E, Karel)
   Vacuumdb script now supports --all option (Peter E)
   ecpg new portable FETCH syntax
   Add ecpg EXEC SQL IFDEF, EXEC SQL IFNDEF, EXEC SQL ELSE, EXEC 
    SQL ELIF and EXEC SQL ENDIF directives
   Add pg_ctl script to control backend startup (Tatsuo)
   Add postmaster.opts.default file to store startup flags (Tatsuo)
   Allow --with-mb=SQL_ASCII
   Increase maximum number of index keys to 16 (Bruce)
   Increase maximum number of function arguments to 16 (Bruce)
   Allow configuration of maximum number of index keys and 
   arguments (Bruce)
   Allow unprivileged users to change their passwords (Peter E)
   Password authentication enabled; required for new users (Peter E)
   Disallow dropping a user who owns a database (Peter E)
   Change initdb option --with-mb to --enable-multibyte
   Add option for initdb to prompts for superuser password (Peter E)
   Allow complex type casts like col::numeric(9,2) and 
   col::int2::float8 (Tom)
   Updated user interfaces on initdb, initlocation, pg_dump, 
    ipcclean (Peter E)
   New pg_char_to_encoding() and pg_encoding_to_char() (Tatsuo)
   New libpq functions PQsetClientEncoding(), PQclientEncoding() 
    (Tatsuo)
   Libpq non-blocking mode (Alfred Perlstein)
   Improve conversion of types in casts that don't specify a length
   New plperl internal programming language (Mark Hollomon)
   Allow COPY IN to read file that do not end with a newline (Tom)
   Indicate when long identifiers are truncated (Tom)
   Allow aggregates to use type equivalency (Peter E)
   Add Oracle's to_char(), to_date(), to_datetime(), to_timestamp(),
    to_number() conversion functions (Karel Zak <zakkr@zf.jcu.cz>)
   Add SELECT DISTINCT ON (expr [, expr ...]) targetlist ... (Tom)
   Check to be sure ORDER BY is compatible with DISTINCT (Tom)
   Add NUMERIC and int8 types to ODBC
   Improve EXPLAIN results for Append, Group, Agg, Unique (Tom)
   Add ALTER TABLE ... ADD FOREIGN KEY (Stephan Szabo)
   Allow SELECT .. FOR UPDATE in PL/pgSQL (Hiroshi)
   Enable backward sequential scan even after reaching EOF (Hiroshi)
   Add btree indexing of boolean values, >= and <= (Don Baccus)
   Print current line number when COPY FROM fails (Massimo)
   Recognize POSIX time zone e.g. "PST+8" and "GMT-8" (Thomas)
   Add DEC as synonym for DECIMAL (Thomas)
   Add SESSION_USER as SQL92 keyword (== CURRENT_USER) (Thomas)
   Implement SQL92 column aliases (aka correlation names) (Thomas)
   Implement SQL92 join syntax (Thomas)
   INTERVAL reserved word allowed as a column identifier (Thomas)
   Implement REINDEX command (Hiroshi)
   Accept ALL in aggregate function SUM(ALL col) (Tom)
   Prevent GROUP BY from using column aliases (Tom)
   New psql \encoding option (Tatsuo)
   Allow PQrequestCancel() to terminate when in waiting-for-lock 
    state (Hiroshi)
   Allow negation of a negative number in all cases
   Add ecpg descriptors (Christof, Michael)
   Allow CREATE VIEW v AS SELECT f1::char(8) FROM tbl
   Allow casts with length, like foo::char(8)
   Add support for SJIS user defined characters (Tatsuo)
   Larger views/rules supported
   Make libpq's PQconndefaults() thread-safe (Tom)
   Disable // as comment to be ANSI conforming, should use -- (Tom)
   Allow column aliases on views CREATE VIEW name (collist)
   Fixes for views with subqueries (Tom)
   Allow UPDATE table SET fld = (SELECT ...) (Tom)
   SET command options no longer require quotes
   Update pgaccess to 0.98.6
   New SET SEED command
   New pg_options.sample file
   New SET FSYNC command (Massimo)
   Allow pg_descriptions when creating tables
   Allow pg_descriptions when creating types, columns, and functions
   Allow psql \copy to allow delimiters(Peter E)
   Allow psql to print nulls as distinct from "" [null](Peter E)

   Types
   -----
   Many array fixes (Tom)
   Allow bare column names to be subscripted as arrays (Tom)
   Improve type casting of int and float constants (Tom)
   Cleanups for int8 inputs, range checking, and type conversion (Tom)
   Fix for SELECT timespan('21:11:26'::time) (Tom)
   netmask('x.x.x.x/0') is 255.255.255.255 instead of 0.0.0.0 
   (Oleg Sharoiko)
   Add btree index on NUMERIC (Jan)
   Perl fix for large objects containing NUL characters
    (Douglas Thomson) 
   ODBC fix for for large objects (free)
   Fix indexing of cidr data type
   Fix for Ethernet MAC addresses (macaddr type) comparisons
   Fix for date/time types when overflows happen (Tom)
   Allow array on int8 (Peter E)
   Fix for rounding/overflow of NUMERIC type, like NUMERIC(4,4) (Tom)
   Allow NUMERIC arrays
   Fix bugs in NUMERIC ceil() and floor() functions (Tom)
   Make char_length()/octet_length including trailing blanks (Tom)
   Made abstime/reltime use int4 instead of time_t (Peter E)
   New lztext data type for compressed text fields
   Revise code to handle coercion of int and float constants (Tom)
   Start at new code to implement a BIT and BIT VARYING type 
    (Adriaan Joubert)
   NUMERIC now accepts scientific notation (Tom)
   NUMERIC to int4 rounds (Tom)
   Convert float4/8 to NUMERIC properly (Tom)
   Allow type conversion with NUMERIC (Thomas)
   Make ISO date style (2000-02-16 09:33) the default (Thomas)
   Add NATIONAL CHAR [ VARYING ] (Thomas)
   Allow NUMERIC round and trunc to accept negative scales (Tom)
   New TIME WITH TIME ZONE type (Thomas)
   Add MAX()/MIN() on time type (Thomas)
   Add abs(), mod(), fac() for int8 (Thomas)
   Rename functions to round(), sqrt(), cbrt(), pow() for float8 
    (Thomas)
   Add transcendental math functions for float8 (Thomas)
   Add exp() and ln() for NUMERIC type (Jan)
   Rename NUMERIC power() to pow() (Thomas)
   Improved TRANSLATE() function (Edwin Ramirez, Tom)
   Allow X=-Y operators  (Tom)
   Allow SELECT float8(COUNT(*))/(SELECT COUNT(*) FROM t)
    FROM t GROUP BY f1; (Tom)
   Allow LOCALE to use indexes in regular expression searches (Tom)
   Allow creation of functional indexes to use default types

   Performance
   -----------
   Prevent exponential space usage with many AND's and OR's (Tom)
   Collect attribute selectivity values for system columns (Tom)
   Reduce memory usage of aggregates (Tom)
   Fix for LIKE optimization to use indexes with multi-byte 
    encodings (Tom)
   Fix r-tree index optimizer selectivity (Thomas)
   Improve optimizer selectivity computations and functions (Tom)
   Optimize btree searching when many equal keys exist (Tom)
   Enable fast LIKE index processing only if index present (Tom)
   Re-use free space on index pages with duplicates (Tom)
   Improve hash join processing (Tom)
   Prevent descending sort if result is already sorted(Hiroshi)
   Allow commuting of index scan query qualifications (Tom)
   Prefer index scans when ORDER BY/GROUP BY is required (Tom)
   Allocate large memory requests in fix-sized chunks for 
    performance (Tom)
   Fix vacuum's performance reducing memory requests (Tom)
   Implement constant-expression simplification
    (Bernard Frankpitt, Tom)
   Use secondary columns to be used to determine start of index 
    scan (Hiroshi)
   Prevent quadruple use of disk space when sorting (Tom)
   Faster sorting by calling fewer functions (Tom)
   Create system indexes to match all system caches
    (Bruce, Hiroshi)
   Make system caches use system indexes (Bruce)
   Make all system indexes unique (Bruce)
   Improve pg_statistics management to help VACUUM speed (Tom)
   Flush backend cache less frequently (Tom, Hiroshi)
   COPY now reuses previous memory allocation, improving 
    performance (Tom)
   Improve optimization cost estimation (Tom)
   Improve optimizer estimate of range queries
    (x > lowbound AND x < highbound) (Tom)
   Use DNF instead of CNF where appropriate (Tom, Taral)
   Further cleanup for OR-of-AND WHERE-clauses (Tom)
   Make use of index in OR clauses
    (x = 1 AND y = 2) OR (x = 2 AND y = 4) (Tom)
   Smarter optimizer for random index page access (Tom)
   New SET variable to control optimizer costs (Tom)
   Optimizer queries based on LIMIT, OFFSET, and EXISTS 
    qualifications (Tom)
   Reduce optimizer internal housekeeping of join paths for 
    speedup (Tom)
   Major subquery speedup (Tom)
   Fewer fsync writes when fsync is not disabled (Tom)
   Improved LIKE optimizer estimates (Tom)
   Prevent fsync in SELECT-only queries (Vadim)
   Index creation uses psort, since psort now faster (Tom)
   Allow creation of sort temp tables > 1 Gig

   Source Tree Changes
   -------------------
   Fix for linux PPC compile
   New generic expression-tree-walker subroutine (Tom)
   Change form() to varargform() to prevent portability problems
   Improved range checking for large integers on Alphas
   Clean up #include in /include directory (Bruce)
   Add scripts for checking includes (Bruce)
   Remove un-needed #include's from *.c files (Bruce)
   Change #include's to use <> and "" as appropriate (Bruce)
   Enable WIN32 compilation of libpq
   Alpha spinlock fix from Uncle George (gatgul@voicenet.com)
   Overhaul of optimizer data structures (Tom)
   Fix to cygipc library (Yutaka Tanida)
   Allow pgsql to work on newer Cygwin snapshots (Dan)
   New catalog version number (Tom)
   Add Linux ARM
   Rename heap_replace to heap_update
   Update for QNX (Dr. Andreas Kardos)
   New platform-specific regression handling (Tom)
   Rename oid8 -> oidvector and int28 -> int2vector (Bruce)
   Included all yacc and lex files into the distribution (Peter E.)
   Remove lextest, no longer needed (Peter E)
   Fix for libpq and psql on Win32 (Magnus)
   Change datetime and timespan into timestamp and interval (Thomas)
   Fix for plpgsql on BSDI
   Add SQL_ASCII test case to the regression test (Tatsuo)
   configure --with-mb now deprecated (Tatsuo)
   NT fixes
   NetBSD fixes Johnny C. Lam (lamj@stat.cmu.edu)
   Fixes for Alpha compiles
   New multibyte encodings           

Chapter 6. Regression Test


       Regression test instructions and analysis. 

       The PostgreSQL regression tests are a comprehensive set of 
      tests for the SQL implementation embedded in PostgreSQL. They 
      test standard SQL operations as well as the extended 
      capabilities of PostgreSQL. 
       There are two different ways in which the regression tests can 
      be run: the "sequential" method and the "parallel" method. The 
      sequential method runs each test script in turn, whereas the 
      parallel method starts up multiple server processes to run 
      groups of tests in parallel. Parallel testing gives confidence 
      that interprocess communication and locking are working 
      correctly. Another key difference is that the sequential test 
      procedure uses an already-installed postmaster, whereas the 
      parallel test procedure tests a system that has been built but 
      not yet installed. (The parallel test script actually does an 
      installation into a temporary directory and fires up a private 
      postmaster therein.) 
       Some properly installed and fully functional PostgreSQL 
      installations can "fail" some of these regression tests due to 
      artifacts of floating point representation and time zone 
      support. The tests are currently evaluated using a simple diff 
      comparison against the outputs generated on a reference system, 
      so the results are sensitive to small system differences. When 
      a test is reported as "failed", always examine the differences 
      between expected and actual results; you may well find that the 
      differences are not significant. 
       The regression tests were originally developed by Jolly Chen 
      and Andrew Yu, and were extensively revised/repackaged by Marc 
      Fournier and Thomas Lockhart. From PostgreSQL v6.1 onward the 
      regression tests are current for every official release. 

Regression Environment


       The regression testing notes below assume the following 
      (except where noted): 
      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). 
       
       Normally, the regression tests should be run as the postgres 
      user since the 'src/test/regress' directory and sub-directories 
      are owned by the postgres user. If you run the regression test 
      as another user the 'src/test/regress' directory tree must be 
      writeable by that user. 
       It was formerly necessary to run the postmaster with system 
      time zone set to PST, but this is no longer required. You can 
      run the regression tests under your normal postmaster 
      configuration. The test script will set the PGTZ environment 
      variable to ensure that timezone-dependent tests produce the 
      expected results. However, your system must provide library 
      support for the PST8PDT time zone, or the timezone-dependent 
      tests will fail. To verify that your machine does have this 
      support, type the following: 

      setenv TZ PST8PDT
      date
          

       
       The "date" command above should have returned the current 
      system time in the PST8PDT time zone. If the PST8PDT database 
      is not available, then your system may have returned the time 
      in GMT. If the PST8PDT time zone is not available, you can set 
      the time zone rules explicitly: 

      setenv PGTZ PST8PDT7,M04.01.0,M10.05.03
          

       
       The directory layout for the regression test area is: 

      Table 6-1. Directory Layout
      Directory  Description
      input       Source files that are converted using make all 
                 into some of the .sql files in the sql 
                 subdirectory. 
      output      Source files that are converted using make all 
                 into .out files in the expected subdirectory. 
      sql         .sql files used to perform the regression tests. 
      expected    .out files that represent what we expect the 
                 results to look like. 
      results     .out files that contain what the results actually 
                 look like. Also used as temporary storage for table 
                 copy testing. 
      tmp_check   Temporary installation created by parallel testing 
                 script. 


       

Regression Test Procedure


       Commands were tested on RedHat Linux version 4.2 using the 
      bash shell. Except where noted, they will probably work on most 
      systems. Commands like ps and tar vary wildly on what options 
      you should use on each platform. Use common sense before typing 
      in these commands. 

      Postgres Regression Test
      1.  Prepare the files needed for the regression test with: 
                     cd /usr/src/pgsql/src/test/regress
                     gmake clean
                     gmake all
                   
          You can skip "gmake clean" if this is the first time you 
         are running the tests. 
          This step compiles a C program with PostgreSQL extension 
         functions into a shared library. Localized SQL scripts and 
         output-comparison files are also created for the tests that 
         need them. The localization replaces macros in the source 
         files with absolute pathnames and user names. 
      2.  If you intend to use the "sequential" test procedure, which 
         tests an already-installed postmaster, be sure that the 
         postmaster is running. If it isn't already running, start 
         the postmaster in an available window by typing 
                postmaster
                   
          or start the postmaster daemon running in the background by 
         typing 
               cd
                     nohup postmaster > regress.log 2>&1 &
                   
          The latter is probably preferable, since the regression 
         test log will be quite lengthy (60K or so, in Postgres 7.0) 
         and you might want to review it for clues if things go 
         wrong. 

         Note: Do not run postmaster from the root account.

          
      3.  Run the regression tests. For a sequential test, type 
                    cd /usr/src/pgsql/src/test/regress
                     gmake runtest
                   
          For a parallel test, type 
                cd /usr/src/pgsql/src/test/regress
                     gmake runcheck
                   
          The sequential test just runs the test scripts using your 
         already-running postmaster. The parallel test will perform a 
         complete installation of Postgres into a temporary 
         directory, start a private postmaster therein, and then run 
         the test scripts. Finally it will kill the private 
         postmaster (but the temporary directory isn't removed 
         automatically). 
      4.  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 of the tests to "fail" due to 
         platform-specific variations. See the next section for 
         details on determining whether a "failure" is significant. 
          Some of the tests, notably "numeric", can take a while, 
         especially on slower platforms. Have patience. 
      5.  After running the tests and examining the results, type 
                  cd /usr/src/pgsql/src/test/regress
                     gmake clean
                   
          to recover the temporary disk space used by the tests. If 
         you ran a sequential test, also type 
                   dropdb regression
                   
          

Regression Analysis


       The actual outputs of the regression tests are in files in the 
      ./results directory. The test script uses diff to compare each 
      output file against the reference outputs stored in the 
      ./expected directory. Any differences are saved for your 
      inspection in ./regression.diffs. (Or you can run diff 
      yourself, if you prefer.) 
       The files might not compare exactly. The test script will 
      report any difference as a "failure", but the difference might 
      be due to small cross-system differences in error message 
      wording, math library behavior, etc. "Failures" of this type do 
      not indicate a problem with Postgres. 
       Thus, it is necessary to examine the actual differences for 
      each "failed" test to determine whether there is really a 
      problem. The following paragraphs attempt to provide some 
      guidance in determining whether a difference is significant or 
      not. 

Error message differences


       Some of the regression tests involve intentional invalid input 
      values. Error messages can come from either the Postgres code 
      or from the host platform system routines. In the latter case, 
      the messages may vary between platforms, but should reflect 
      similar information. These differences in messages will result 
      in a "failed" regression test which can be validated by 
      inspection. 

Date and time differences


       Most of the date and time results are dependent on timezone 
      environment. The reference files are generated for timezone 
      PST8PDT (Berkeley, California) and there will be apparent 
      failures if the tests are not run with that timezone setting. 
      The regression test driver sets environment variable PGTZ to 
      PST8PDT to ensure proper results. 
       Some of the queries in the "timestamp" test will fail if you 
      run the test on the day of a daylight-savings time changeover, 
      or the day before or after one. These queries assume that the 
      intervals between midnight yesterday, midnight today and 
      midnight tomorrow are exactly twenty-four hours ... which is 
      wrong if daylight-savings time went into or out of effect 
      meanwhile. 
       There appear to be some systems which do not accept the 
      recommended syntax for explicitly setting the local time zone 
      rules; you may need to use a different PGTZ setting on such 
      machines. 
       Some systems using older timezone libraries fail to apply 
      daylight-savings corrections to pre-1970 dates, causing 
      pre-1970 PDT times to be displayed in PST instead. This will 
      result in localized differences in the test results. 

Floating point differences


       Some of the tests involve computing 64-bit (float8) numbers 
      from table columns. Differences in results involving 
      mathematical functions of float8 columns have been observed. 
      The float8 and geometry tests are particularly prone to small 
      differences across platforms. Human eyeball comparison is 
      needed to determine the real significance of these differences 
      which are usually 10 places to the right of the decimal point. 
       Some systems signal errors from pow() and exp() differently 
      from the mechanism expected by the current Postgres code. 

Polygon differences


       Several of the tests involve operations on geographic date 
      about the Oakland/Berkley CA street map. The map data is 
      expressed as polygons whose vertices are represented as pairs 
      of float8 numbers (decimal latitude and longitude). Initially, 
      some tables are created and loaded with geographic data, then 
      some views are created which join two tables using the polygon 
      intersection operator (##), then a select is done on the view. 
      When comparing the results from different platforms, 
      differences occur in the 2nd or 3rd place to the right of the 
      decimal point. The SQL statements where these problems occur 
      are the following: 

          QUERY: SELECT * from street;
                QUERY: SELECT * from iexit;
              

       

Random differences


       There is at least one case in the "random" test script that is 
      intended to produce random results. This causes random to fail 
      the regression test once in a while (perhaps once in every five 
      to ten trials). Typing 

               diff results/random.out expected/random.out
              

       should produce only one or a few lines of differences. You 
      need not worry unless the random test always fails in repeated 
      attempts. (On the other hand, if the random test is never 
      reported to fail even in many trials of the regress tests, you 
      probably should worry.) 

The "expected" files


       The ./expected/*.out files were adapted from the original 
      monolithic expected.input file provided by Jolly Chen et al. 
      Newer versions of these files generated on various development 
      machines have been substituted after careful (?) inspection. 
      Many of the development machines are running a Unix OS variant 
      (FreeBSD, Linux, etc) on Ix86 hardware. The original 
      expected.input file was created on a SPARC Solaris 2.4 system 
      using the postgres5-1.02a5.tar.gz source tree. It was compared 
      with a file created on an I386 Solaris 2.4 system and the 
      differences were only in the floating point polygons in the 3rd 
      digit to the right of the decimal point. The original 
      sample.regress.out file was from the postgres-1.01 release 
      constructed by Jolly Chen. It may have been created on a DEC 
      ALPHA machine as the Makefile.global in the postgres-1.01 
      release has PORTNAME=alpha. 

Platform-specific comparison files


       Since some of the tests inherently produce platform-specific 
      results, we have provided a way to supply platform-specific 
      result comparison files. Frequently, the same variation applies 
      to multiple platforms; rather than supplying a separate 
      comparison file for every platform, there is a mapping file 
      that defines which comparison file to use. So, to eliminate 
      bogus test "failures" for a particular platform, you must 
      choose or make a variant result file, and then add a line to 
      the mapping file, which is "resultmap". 
       Each line in the mapping file is of the form 

                  testname/platformnamepattern=comparisonfilename
              

       The test name is just the name of the particular regression 
      test module. The platform name pattern is a pattern in the 
      style of expr(1) (that is, a regular expression with an 
      implicit ^ anchor at the start). It is matched against the 
      platform name as printed by config.guess. The comparison file 
      name is the name of the substitute result comparison file. 
       For example: the int2 regress test includes a deliberate entry 
      of a value that is too large to fit in int2. The specific error 
      message that is produced is platform-dependent; our reference 
      platform emits 

          ERROR:  pg_atoi: error reading "100000": Numerical result 
      out of range
              

       but a fair number of other Unix platforms emit 

          ERROR:  pg_atoi: error reading "100000": Result too large
              

       Therefore, we provide a variant comparison file, 
      int2-too-large.out, that includes this spelling of the error 
      message. To silence the bogus "failure" message on HPPA 
      platforms, resultmap includes 

                 int2/hppa=int2-too-large
              

       which will trigger on any machine for which config.guess's 
      output begins with 'hppa'. Other lines in resultmap select the 
      variant comparison file for other platforms where it's 
      appropriate. 
