As a general rule, the internal data storage format is subject to change between releases of Postgres. This does not apply to different "patch levels", these always have compatible storage formats. For example, releases 6.5.3, 7.0.1, and 7.1 are not compatible, whereas 7.0.2 and 7.0.1 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, the Installation Instructions carry these details.
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 kill -INT `cat /usr/local/pgsql/postmaster.pid` mv /usr/local/pgsql /usr/local/pgsql.old cd /usr/src/postgresql-7.1 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.