Re: Upgrading from PG 8.2.5 to 9.1.13

Great, thank you very much for this clarification :)

Marc

Am 18.08.2014 02:34, schrieb Keith:
> I'm not quite familiar with all that the pg_freespacemap contrib module
> did back in 8.2, but if it's anything like the current one, it just
> provided queries to return data for you to act upon.
> I've been using PostgreSQL since 8.4 myself and since then have found no
> typical usage for the pg_freespacemap extension any longer. I wouldn't
> worry about its functions not restoring properly in this case unless you
> find something to the contrary in your migration process.
>
>
> On Sun, Aug 17, 2014 at 11:36 AM, Marc Richter <mail@marc-richter.info
> <mailto:mail@marc-richter.info>> wrote:
>
>     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>
>      > <mailto: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>
>      >     <mailto: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
>     <mailto:pgsql-novice@postgresql.org>)
>     To make changes to your subscription:
>     http://www.postgresql.org/mailpref/pgsql-novice
>
>

--
Freenode IRC: Judge | Homepage: http://www.marc-richter.info
PGP Key: 75D429DE | GitHub: The-Judge | Bitbucket: Judge82