According to Paul Ramsey:
First, for patch version increases (e.g. X.Y.Z -> X.Y.(Z+1)) in
PostgreSQL and PostGIS you do not need to do anything at all other
than install the new software. The data can remain in place and
everything will Just Work.
For minor version increases in PostgreSQL (e.g. X.Y.Z -> X.(Y+1).Z)
you need to dump and restore. For minor version increases in PostGIS,
you need to do a "soft upgrade", which means leaving the data in
place, but running the upgrade scripts (e.g.
postgis_upgrade_14_to_15.sql) after you install the software update.
Finally, for major version increases in PostgreSQL and PostGIS (e.g.
X.Y.Z -> (X+1).Y.Z) you need to dump and restore.
Did you store data in the public schema?
Which brings me to the actual point I want to make: you can ensure the
greatest ease in doing dump and restore of PostGIS data if you ensure
that you store no data in the "public" schema.
Not all is lost though if you stored data in the public schema
"But Paul," you say, "I already have a full database dump, does that
mean I'm SOL?" No, but you will need a strong stomach. First, set up
your new PostgreSQL. Create a blank database, load PostGIS into it.
Now, load your backup file into that database. You will see lots of
errors. However, these errors will be caused by old PostGIS function
and type definitions from your dump file conflicting with the existing
type definitions in your database. And since you want the new
definitions, not the old ones, that's OK. Your load, despite all the
noise and errors, should actually work. Once it's done, you can move
your data into a nice separate schema, so that next time you can do a
clean, error-free restore.
Have you tested if it works despite the errors?
The PostGIS site also has a section on upgrading PostGIS.