Add new information for utility commands.

[postgresql] / INSTALL

POSTGRESQL INSTALLATION INSTRUCTIONS
Copyright (c) 1997 Regents of  the University of California

This is file /usr/src/pgsql/INSTALL.  It contains notes on how to install
PostgreSQL v6.4.  Up to date information on PostgreSQL may be found at
http://www.postgresql.org.

PostgreSQL is an RDBMS database server.  It is not completely ANSI SQL
compliant, but with each release it gets closer.

PostgreSQL, formerly called Postgres95, is a derivative of Postgres 4.2
(the last release of the UC Berkeley research project).  For copyright
terms for PostgreSQL, please see the file named COPYRIGHT.  This version
was developed by a team of developers on the Postgres developers mailing
list.  Version 1 (through 1.01) was developed by Jolly Chen and Andrew Yu.

The installation notes below assume the following (except where noted):
  - Commands are Unix-compatible. See note below.
  - Defaults are used except where noted.
  - User postgres is the Postgres superuser.
  - The source path is /usr/src/pgsql (other paths are possible).
  - The runtime path is /usr/local/pgsql (other paths are possible).

Commands were tested on RedHat Linux version 4.0 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.

Our Makefiles require GNU make (called gmake in this document) and
also assume that "install" accepts BSD options. The INSTALL
variable in the Makefiles is set to the BSD-compatible version of
install. On some systems, you will have to find a BSD-compatible
install command (eg. bsdinst, which comes with the MIT X Window System
distribution) 


REQUIREMENTS TO RUN POSTGRESQL
------------------------------

PostgreSQL has been tested on the following platforms:

   aix            IBM on AIX 3.2.5 or 4.x
   alpha          DEC Alpha AXP on Digital Unix 2.0, 3.2, 4.0
   BSD44_derived  OSs derived from 4.4-lite BSD (NetBSD, FreeBSD)
   bsdi           BSD/OS 2.0, 2.01, 2.1, 3.0
   dgux           DG/UX 5.4R4.11
   hpux           HP PA-RISC on HP-UX 9.0, 10
   i386_solaris   i386 Solaris
   irix5          SGI MIPS on IRIX 5.3
   linux          Intel x86 on Linux 2.0 and Linux ELF
                  SPARC on Linux ELF
                  PPC on Linux ELF
                  (For non-ELF Linux, see LINUX_ELF below).
   sco            SCO 3.2v5
   sparc_solaris  SUN SPARC on Solaris 2.4, 2.5, 2.5.1
   sunos4         SUN SPARC on SunOS 4.1.3
   svr4           Intel x86 on Intel SVR4 and MIPS
   ultrix4        DEC MIPS on Ultrix 4.4

PostgreSQL has known problems/bugs on the following platforms:

   nextstep       Motorola MC68K or Intel x86 on NeXTSTEP 3.2

PostgreSQL is also known to work on a number of other platforms that the
authors have not personally tested.

You should have at least 8 MB of memory and at least 45 MB of disk space
to hold the source, binaries, and user databases.  After installation
you may reduce this to about 3 Mbytes plus space for user databases.

To those upgrading from PostgreSQL 6.3.*:
----------------------------------------

A dump/restore is required for those running 6.3.*, or you can use the
new pg_upgrade command to upgrade your data files without
dumping/loading them.  See the new pg_upgrade manual page.

To those doing a fresh install or upgrading from previous releases of
PostgreSQL:
----------------------------------------------

  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 PostgreSQL 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 account postgres if it does not already exist.

  3) Log into account postgres.

  3a) Check that you have sufficient disk space.  You will need about
      17 Mbytes for /usr/src/pgsql, about 2 Mbytes for /usr/local/pgsql
      (excluding your database) and 1 Mbyte for an empty database.
      For the regression tests, you will need an extra 20 Mbytes.
      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 5 MB
      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 command "df -k".

  4) Ftp file ftp://ftp.postgresql.org/pub/postgresql-6.4.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.  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.

     To install it, type the following:
        cd
        gunzip -c flex-2.5.4.tar.gz | tar xvf -
        cd flex-2.5.4
        configure --prefix=/usr
        make
        make check
        # You must be root when typing the next line.
        make install
        cd
        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 link
     /usr/bin/flex++ which points to flex.

  6) 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.  Type (with the gunzip line and the following line typed as one
     line):
        cd
        gunzip -c postgresql-6.4.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, 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, use "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 appropriate files pgsql/migration/*.

     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 "???" replaced by the process id for process
     "postmaster".  (Do not use the id for process "grep postmaster".)  Type
       kill ???
     with "???" modified as indicated.

  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; be consistant with your configuration
     in step (11).
     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-6.4.tar.gz | tar xvf -

 11) Configure the source code for your system.  It is this step at which
     you can specify your actual source path and installation paths for
     the build process (see the --prefix option below).  Type
        cd /usr/src/pgsql/src
        ./configure

     The configure program will list the template files available and
     ask you to choose one.  A lot of times, an appropriate template
     file is chosen for you, and you can just press Enter to accept the
     default.  If the default is not appropriate, then type in the
     appropriate template file and press Enter.  (If you do this, then
     send email to scrappy@hub.org stating the output of the program
     './config.guess' and what the template file should be.)

     Once you have entered the template file, you will be asked a
     number of questions about your particular configuration.  These
     can be skipped by adding parameters to the configure command above.
     The following parameters can be tagged onto the end of the configure
     command:

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

       --enable-hba       Enables Host Based Authentication (DEFAULT)

       --enable-locale    Enables USE_LOCALE

       --enable-cassert   Enables ASSERT_CHECKING

       --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.
                          (If the configure script cannot find the
                          specified template file, it will ask you for
                          one).

       --with-pgport=PORT Sets the port that the postmaster process
                          listens for incoming connections on.  The
                          default for this is port 5432.

       --with-tcl         Enables programs requiring Tcl/Tk and X11,
                          including pgtclsh and libpgtcl.

       --with-perl        Enables the perl interface.

       --with-includes=DIRS
                          Include DIRS in list of directories searched
                          for header files.  (Typical use will need
                          --with-includes=/usr/local/include)

       --with-libs=DIRS
       --with-libraries=DIRS
                          Include DIRS in list of directories searched
                          for archive libraries.  (Typical use will need
                          --with-libraries=/usr/local/lib)

       --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.

     As an example, here is the configure script I use on a Sparc
     Solaris 2.5 system with /opt/postgres being the install base.

       % ./configure --prefix=/opt/postgres 
                --with-template=sparc_solaris-gcc --with-pgport=5432
                --enable-hba

     Of course, in a real shell, you would type these three lines all
     on the same line.

 12) 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."  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.)

     If your computer does not have gmake (GNU make) then try running
     make instead throughout the rest of these notes.

     Please note that 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 an error stating that the flex command
     cannot be found then install flex as described earlier.  Next,
     change directory back to this directory, type "make clean", then
     recompile again.

 13) 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.

 14) If necessary, tell UNIX how to find your shared libraries.  If you
     are using Linux-ELF do ONE of the following, preferably the first:

       a) As root, edit file /etc/ld.so.conf.  Add 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.

 15) If it has not already been done, then prepare account postgres
     for using PostgreSQL.  Any account that will use PostgreSQL must
     be similarily prepared.  (The following instructions are for a
     bash shell.  Adapt accordingly for other shells.)

     Add the following lines to your login 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

     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

 16) Create the database.  DO NOT DO THE FOLLOWING AS ROOT!  This would
     be a major security hole.  Type
        initdb

 17) 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 finsihed.

     If you are upgrading, you can NOT copy file pg_hba.conf from your
     old database on top of the one in your new database.  You will
     have to re-do your changes.


 18) If you wish to skip the regression tests then skip to step 21.

     The file /usr/src/pgsql/src/test/regress/README has detailed
     instructions for running and interpreting the regression tests.
     A short version follows here:

     Start the postmaster in preparation for the regression tests.  First,
     set the timezone for Berkeley, California.  On some systems you may do
     this by setting environment variable TZ.  I.e., using bash, type
        export TZ=PST8PDT

     Now start the postmaster daemon running in the background by typing
        cd
        nohup postmaster > regress.log 2>&1 &

     Run postmaster from your Postgres super user account (typically
     account postgres).  DO NOT RUN POSTMASTER FROM THE ROOT ACCOUNT.

 19) Run the regression tests.  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 of the tests to
     "fail".  For the failed tests, use diff to compare the files in
     directories ./results and ./expected.  If float8 failed, type
     something like:
        cd /usr/src/pgsql/src/test/regress
        diff -w expected/float8.out results

    "Failed" tests may have failed due to slightly different error messages,
     output formatting, failure to set the timezone correctly for your
     platform, etc.  "Failures" of this type do not indicate a problem with
     PostgreSQL.

     For a i686/Linux-ELF platform, no tests failed since this is the
     v6.4 regression testing reference platform.

     For the SPARC/Linux-ELF platform, using the 970525 beta version of
     PostgreSQL v6.2 the following tests "failed":
     float8 and geometry "failed" due to minor precision differences in
     floating point numbers.  select_views produces massively different output,
     but the differences are due to minor floating point differences.

     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 PostgreSQL.  However, keep in mind that this is likely
     to be the most solid release of PostgreSQL to date, incorporating many
     bug fixes from v6.2.1, and that previous versions of PostgreSQL have been
     in use successfully for some time now.

     After running the tests, type
        destroydb regression
        cd /usr/src/pgsql/src/test/regress
        gmake clean

 20) Stop the postmaster as described in step 7.  Then restore the
     timezone to it's normal setting.  If you changed the timezone by
     modifying environment variable TZ then one way to do this is to
     log out of, then back into, account postgres.

 21) Start the postmaster daemon running.  Type
        cd
        nohup postmaster > server.log 2>&1 &
     Run postmaster from your Postgres super user account (typically
     account postgres).  DO NOT RUN POSTMASTER FROM THE ROOT ACCOUNT.

 22) If you haven't already done so, this would be a good time to modify
     your computer so that it will automatically start postmaster whenever
     you boot your computer.

     Here are some suggestions on how to do this, contributed by various
     users.

     Whatever you do, postmaster must be run by user 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.

       a) 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"

       b) 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 postgres -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.  Note:  Unlike most
          other examples, this one has been tested.

       c) In RedHat v4.0 Linux edit file /etc/inittab to contain the
          following 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.)

       d) The contrib/linux area of the PostgreSQL distribution has an example
          init.d script compatible with and tested using recent RedHat packages.

 22a) 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:

        a) Run the SQL command vacuum.  This will clean up your database.
        b) Back up your system.  (You should probably keep the last few
           backups on hand.)  Ideally, 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.)

 23) If you are upgrading an existing system then reload 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 YourTable set PathCol = UpgradePath(PathCol);
        update YourTable set PolyCol = UpgradePoly(PolyCol);
        ...
        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.

 24) If you are a new user, you may wish to play with Postgres as described
     below.

 25) Clean up after yourself.  Type
        rm -rf /usr/src/pgsql_6_0
        rm -rf /usr/local/pgsql_6_0
        # Also delete old database directory tree if it is not in
        #  /usr/local/pgsql_6_0/data
        rm ~/postgresql-6.4.tar.gz

 26) You will probably want to print out the documentation.  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
        # Print out the man pages.
        man -a -t /usr/local/pgsql/man/*/* > manpage.ps
        gshp -sOUTPUTFILE=manpage.hp manpage.ps
        rm manpage.ps
        lpr -l -s -r manpage.hp
        # Print out the Postgres95 User Manual, version 1.0,
        #  Sept. 5, 1996.
        cd /usr/src/pgsql/doc
        gshp -sOUTPUTFILE=userguide.hp userguide.ps
        lpr -l -s -r userguide.hp

     If you are a developer, you will probably want to also print out
     the Postgres Implemention Guide, version 1.0, October 1, 1995.
     This is a WWW document located at
     http://www.postgresql.org/docs/impguide.

 27) The Postgres team wants to keep PostgreSQL working on all of the
     supported platforms.  We therefore ask you to let us know if you did
     or did not get PostgreSQL to work on you system.  Please send a
     mail message to pgsql-ports@postgresql.org telling us the following:
       - The version of PostgreSQL (6.4, 6.3.2, beta 970703, etc.).
       - Your operating system (i.e. RedHat v4.0 Linux v2.0.26).
       - Your hardware (SPARC, i486, etc.).
       - 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.

 28) Now create, access and manipulate databases as desired.  Write client
     programs to access the database server.  In other words, ENJOY!


PLAYING WITH POSTGRESQL
-----------------------

After PostgreSQL is installed, a database system is created, a postmaster
daemon is running, and the regression tests have passed, you'll want to 
see PostgreSQL do something.  That's easy.  Invoke the interactive interface
to PostgreSQL, psql, and start typing SQL:

  $ 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:

  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;
INSERT 773248

(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.)

template1=> \c foo
closing connection to database: template1
connecting to new database: foo

(\ commands aren't SQL, so no semicolon.  Use \? to see all the \ commands.)

foo=> CREATE TABLE bar (column1 int4, column2 char16);
CREATE

foo=> \d bar

...

You get the idea.


QUESTIONS?  BUGS?  FEEDBACK?
----------------------------

First, read the files in directory /usr/src/pgsql/doc.  The FAQ in
this directory may be particularly useful.

If PostgreSQL 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.

Mail questions to pgsql-questions@postgresql.org.  For more information
on the various mailing lists, see http://www.postgresql.org under mailing
lists.


----------------------------------------------------------------------

Porting Notes (these notes may be out of date):
-------------

Ultrix4.x:
        You need to install the libdl-1.1 package since Ultrix 4.x doesn't
        have a dynamic loader. It's available in
           s2k-ftp.CS.Berkeley.EDU:pub/personal/andrew/libdl-1.1.tar.Z

Linux:
        A linux-2.0.30/libc-5.3.12/RedHat-4.2 running on a dual processor
        i686 is the regression testing reference machine.
        The linux-elf port installs cleanly. If you are using an
        i486 processor or higher, you can edit template/linux-elf
        to include "-m486" as a compiler option. configure does not
        detect that sigsetjmp() is available, but you can edit
        include/config.h after running configure and before running
        make to include "#define HAVE_SIGSETJMP 1". Note that I have
        not seen any difference in PostgreSQL behavior either way.
                                (Thomas G. Lockhart
                                <lockhart@alumni.caltech.edu> 97/10/14)

        For non-ELF Linux, the dld library MUST be obtained and installed on
        the system. It enables dynamic link loading capability to the Postgres
        port. The dld library can be obtained from the sunsite linux
        distributions. The current name is dld-3.2.5.
                                (Jalon Q. Zimmerman
                                <sneaker@powergrid.electriciti.com> 5/11/95)

BSD/OS:
        For BSD/OS 2.0 and 2.01, you will need to get the GNU dld library.

NeXT:
        The NeXT port was supplied by Tom R. Hageman <tom@basil.icce.rug.nl>.
        It requires a SysV IPC emulation library and header files for
        shared libary and semaphore stuff.   Tom just happens to sell such
        a product so contact him for information.  He has also indicated that
        binary releases of PostgreSQL for NEXTSTEP will be made available to
        the general public.  Contact Info@RnA.nl for information.