Re: Upgrading from PG 8.2.5 to 9.1.13

On Fri, Aug 15, 2014 at 8:31 AM, Marc Richter <mail(at)marc-richter(dot)info>
wrote:

> 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(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-novice
>

If your reasoning for having this contrib module installed was to manage
the freespace mapping issues prior to improvements added in 8.4, you may
not need this contrib module anymore and can ignore the errors.

http://www.chesnok.com/daily/2009/02/10/fsm-visibility-map-and-new-vacuum-awesomeness/