As a general rule, the internal data storage format is subject to change between releases of PostgreSQL. This does not apply to different "patch levels", these always have compatible storage formats. For example, releases 7.0.1, 7.1.2, and 7.2 are not compatible, whereas 7.1.1 and 7.1.2 are. When you update between compatible versions, then you can simply reuse the data area in disk by the new executables. Otherwise you need to "back up" your data and "restore" it on the new server, using pg_dump. (There are checks in place that prevent you from doing the wrong thing, so no harm can be done by confusing these things.) The precise installation procedure is not subject of this section, these details are in Chapter 1.
The least downtime can be achieved by installing the new server in a different directory and running both the old and the new servers in parallel, on different ports. Then you can use something likepg_dumpall, otherwise you will obviously lose that data. See Chapter 4 for information on how to prohibit access. In practice you probably want to test your client applications on the new setup before switching over.
If you cannot or do not want to run two servers in parallel you can do the back up step before installing the new version, bring down the server, move the old version out of the way, install the new version, start the new server, restore the data. For example:
pg_dumpall > backup pg_ctl stop mv /usr/local/pgsql /usr/local/pgsql.old cd /usr/src/postgresql-7.2.8 gmake install initdb -D /usr/local/pgsql/data postmaster -D /usr/local/pgsql/data psql < backup
Note: When you "move the old installation out of the way" it is no longer perfectly usable. Some parts of the installation contain information about where the other parts are located. This is usually not a big problem but if you plan on using two installations in parallel for a while you should assign them different installation directories at build time.
One caveat for people who install the new distribution in a different location than the old:
If you have defined any functions, the import utility needs to do the equivalent of "createlang plpgsql". The dump from the old database will contain something like this:
CREATE FUNCTION "plpgsql_call_handler" ( ) RETURNS opaque AS '/usr/lib/pgsql/plpgsql.so' LANGUAGE 'C';
CREATE TRUSTED PROCEDURAL LANGUAGE 'plpgsql' HANDLER "plpgsql_call_handler" LANCOMPILER 'PL/pgSQL';
This contains the full path to the plpgsql.so of the old distribution. In order to successfully restore all functions to the new database, you need to manually fix this path to point to the plpgsql.so of the new distribution.
There is a mistake in a latter example script with a temporary file.
If you run it as is, you will get this error message:
psql: FATAL 1: Database "pgsql" does not exist in the system catalog.
To avoid it and let the upgrade pass, just modify the last script line to
psql -d template1 < backup