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.3.2. 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 NOT required for those running 6.3. A 'make distclean', 'make', and 'make install' is all that is required. This last step should be performed while the postmaster is not running. You should re-link any custom applications that use PostgreSQL libraries. 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.3.2.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.3.2.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.3.2.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.3.2 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.3.2.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.3.2, 6.2.1, 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 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 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 . 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.