Re: Upgrading from PG 8.2.5 to 9.1.13

Hey Keith,

the issue is, that I do not know what the reason was to use it this way
several years ago. Unfortunately, no one is employed in the company
anymore who might know this.
I have a database that should be migrated to newer PostgreSQL version,
which is several years old and no one knows about the details really.
I'm a system administrator and don't know even plain SQL well. So I
don't know about PostgreSQL's internal Data Structure even more.

So, these errors only mean that the pg_freespacemap - functions won't
work and there will no data be missing?

Am 15.08.2014 18:15, schrieb Keith:

>
>
>
> On Fri, Aug 15, 2014 at 8:31 AM, Marc Richter <mail@marc-richter.info

> <mailto:mail@marc-richter.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@postgresql.org

>     <mailto:pgsql-novice@postgresql.org>)

>     To make changes to your subscription:

>     http://www.postgresql.org/__mailpref/pgsql-novice

>     <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/
>
>


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