make sure that your database is not updated during or after the backup. this does not affect the integrity of the backup, but the changed data would of course not be included. if necessary, edit the permissions in the file /usr/local/pgsql/data/pg_hba.conf (or equivalent) to disallow access from everyone except you.

to back up your database installation, type:

pg_dumpall > outputfile

if you need to preserve oids (such as when using them as foreign keys), then use the -o option when running pg_dumpall.

to make the backup, you can use the pg_dumpall command from the version you are currently running. for best results, however, try to use the pg_dumpall command from postgresql 8.2devel, since this version contains bug fixes and improvements over older versions. while this advice might seem idiosyncratic since you haven't installed the new version yet, it is advisable to follow it if you plan to install the new version in parallel with the old version. in that case you can complete the installation normally and transfer the data later. this will also decrease the downtime.

if you are installing the new version at the same location as the old one then shut down the old server, at the latest before you install the new files:

pg_ctl stop

on systems that have postgresql started at boot time, there is probably a start-up file that will accomplish the same thing. for example, on a red hat linux system one might find that

/etc/rc.d/init.d/postgresql stop

works.

very old versions might not have pg_ctl. if you can't find it or it doesn't work, find out the process id of the old server, for example by typing

ps ax | grep postmaster

and signal it to stop this way:

kill -int processid

if you are installing in the same place as the old version then it is also a good idea to move the old installation out of the way, in case you have trouble and need to revert to it. use a command like this:

mv /usr/local/pgsql /usr/local/pgsql.old