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(at)marc-richter(dot)info
> <mailto: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
> <mailto:pgsql-novice(at)postgresql(dot)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/
>
>