I recently upgraded to PostgreSQL 7.2 and had similar problems. Because I didn't use dumpall, I had to recreate my users and groups.

While pg_dumpall will dump all the relevant data, it doesn't support dumping large objects, which is fine for most people who don't use such complex objects in a database.

Personally, I would use `pg_dumpall -g` to dump the global information, and then use pg_dump to dump my inidividual databases to separate files. I do not have many databases, so this is a viable option. This allows me to keep separate files with only the relevant data for a given database. One database in particular that I have is for a school project that needs more care taken with it than my own personal databases.

Also, it is preferable to use one of the non-script outputs. The -F c parameter to pg_dump will output PostgreSQL native format that is compressed by default and also allows for reordering of data/schema loading. -F t produces a tar'd output that is an inbetween the benefits of a script and the -F c format. Both the tar and custom output can handle large objects.

If you need to inspect the data with grep, you can use pg_restore without a database argument, and it will produce a script that you could use to restore the data or make changes.

As you can see, it makes quite a difference in size between the different formats.

gzipping the -F c dump was the smallest, but it wasn't a huge gain from the normal -F c dump size.

While the alternate format outputs aren't as portable, they are ideal for backups. You do not need to pass the same -F parameter to pg_restore as you did with pg_dump, it can determine the type automatically.