Re: Upgrading from PG 8.2.5 to 9.1.13

Hi everyone,

Unfortunately, I'm stuck :P

Referring to the suggestion, to simply use pg_dumpall / psql to migrate a PostgreSQL 8.2 to a 9.1 database server, I'm facing the following issue right now:

The functions from contrib extension "pg_freespacemap" was used in 8.2 . pg_freespacemap is installed in 9.1, too, but I get the following kind of errors when inserting the dump:

ERROR:  couldn't find function »pg_freespacemap_pages« in file »/usr/lib/postgresql/9.1/lib/pg_freespacemap.so«
ERROR:  function public.pg_freespacemap_pages() doesn't exist
ERROR:  couldn't find function »pg_freespacemap_relations« in file »/usr/lib/postgresql/9.1/lib/pg_freespacemap.so«
ERROR:  function public.pg_freespacemap_relations() doesn't exist
ERROR:  column pg_locks.transaction  doesn't exist
LINE 2: ...locks.classid, pg_locks.objid, pg_locks.objsubid, pg_locks."...
ERROR:  relation »public.System.Lockview«  doesn't exist

When I have a look at the list of functions in postgres.public, there seem to exist only two, both named "pg_freespace()".

What am I doing wrong? Is this a serious error or can it safely be ignored?

Best regards, Marc


Am 08.08.2014 16:08, schrieb Albe Laurenz:

Marc Richter wrote:

First of all, I'm sorry for the length of this mail, but I want to get a
full description of steps which might be necessary to proceed to upgrade
a PostgreSQL server from 8.2.5 to 9.1.13. And these are all steps I
found, studying the docs.

I'm quite unexperienced with PostgreSQL and need to do an upgrade from
8.2.5 to something recent. Since we are running Debian wheezy as
default, which uses 9.1.13 currently, this is the destination version to
upgrade to.

[...]

As a general rule of thumb, I understand that one should use that
version of pg_dump/pg_dumpall and psql that ships with the newer version
when updating from a major release to another.

Right.

[...]

>

There are basically two kinds of upgrade:
- Minor release upgrade from version x.y.a to version x.y.b, in
   which all you normally do is replace the binaries and restart the database.
- Major release upgrade from x.a.y to x.b.y (with b > a) or
   from a.x.y to b.x.y (with b > a).
   These are done with pg_dumpall and restore or (in later versions)
   with pg_upgrade.

All of the issues you picked from the release notes ar only relevant for
minor release upgrades to fix the database data.

With pg_dumpall you create a logical copy of the database, and the
database is rebuilt from scratch during restore, so all of these problems
will not occur (e.g., Indexes will be rebuilt and cannot be corrupt).

So it all boils own to pg_dump and restore, an the relevant part of the
release notes is the one that points out incompatibilities to previous versions.
These might bite your application after the upgrade.

Yours,
Laurenz Albe

--
Sent via pgsql-novice mailing list (pgsql-novice@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-novice