Re: Upgrading from PG 8.2.5 to 9.1.13 - Mailing list pgsql-novice
From | Marc Richter |
---|---|
Subject | Re: Upgrading from PG 8.2.5 to 9.1.13 |
Date | |
Msg-id | 53F24F2D.6040904@marc-richter.info Whole thread Raw |
In response to | Re: Upgrading from PG 8.2.5 to 9.1.13 (Keith <keith@keithf4.com>) |
List | pgsql-novice |
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
pgsql-novice by date: