Thread: Problem with pg_upgrade 9.0 -> 9.1
Hi, I was trying to upgrade my Postgres 9.0 installation using pg_upgrade. Running it first with --check revealed no problems. The when I did the actual migration, the following happened: =========== start console output ======================================== Performing Consistency Checks ----------------------------- Checking current, bin, and data directories ok Checking cluster versions ok Checking database user is a superuser ok Checking for prepared transactions ok Checking for reg* system oid user data types ok Checking for contrib/isn with bigint-passing mismatch ok Creating catalog dump ok Checking for prepared transactions ok Checking for presence of required libraries ok | If pg_upgrade fails after this point, you must | re-initdb the new cluster before continuing. | You will also need to remove the ".old" suffix | from c:/Daten/db/pgdata90/global/pg_control.old. Performing Upgrade ------------------ Adding ".old" suffix to old global/pg_control ok Analyzing all rows in the new cluster ok Freezing all rows on the new cluster ok Deleting new commit clogs ok Copying old commit clogs to new server 1 Datei(en) kopiert ok Setting next transaction id for new cluster ok Resetting WAL archives ok Setting frozenxid counters in new cluster ok Creating databases in the new cluster ok Adding support functions to new cluster ok Restoring database schema to new cluster psql:C:/Daten/db/pg_upgrade_dump_db.sql:6024: WARNING: => isdeprecated as an operator name DETAIL: This name may be disallowed altogether in future versions of PostgreSQL. ok Removing support functions from new cluster ok Restoring user relation files Mismatch of relation id: database "dellstore", old relid 83613, new relid 16530 Failure, exiting =========== end console output ======================================== Anything I can do about, or do I need to upgrade "the old way"? Regards Thomas
Thomas Kellerer, 17.09.2011 12:32: > I was trying to upgrade my Postgres 9.0 installation using pg_upgrade. Running it first with --check revealed no problems. > > The when I did the actual migration, the following happened: > > > Mismatch of relation id: database "dellstore", old relid 83613, new relid 16530 > Failure, exiting > I now got the same error (alas with a different relation id) while migrating a completely different data directory. Anything I can do to help find the reason for this problem (or bug?) Unfortuantely the data contains some confidential information so I cannot make it available. Regards Thomas
Thomas Kellerer wrote: > Thomas Kellerer, 17.09.2011 12:32: > > I was trying to upgrade my Postgres 9.0 installation using pg_upgrade. Running it first with --check revealed no problems. > > > > The when I did the actual migration, the following happened: > > > > > > Mismatch of relation id: database "dellstore", old relid 83613, new relid 16530 > > Failure, exiting > > > > I now got the same error (alas with a different relation id) while > migrating a completely different data directory. > > Anything I can do to help find the reason for this problem (or bug?) > > Unfortuantely the data contains some confidential information so I > cannot make it available. This bug was fixed just after 9.1.1 was released. The bug is that Windows doesn't properly pass the right flags for the oid set functions to operate. If you can compile the git 9.1.X current, the fix is in there; the fix will be in 9.1.2. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
Bruce Momjian, 06.10.2011 02:15: >> I now got the same error (alas with a different relation id) while >> migrating a completely different data directory. >> >> Anything I can do to help find the reason for this problem (or bug?) >> >> Unfortuantely the data contains some confidential information so I >> cannot make it available. > > This bug was fixed just after 9.1.1 was released. The bug is that > Windows doesn't properly pass the right flags for the oid set functions > to operate. If you can compile the git 9.1.X current, the fix is in > there; the fix will be in 9.1.2. > Thanks for the feedback. As those were only development databases, it was no big deal to do the migration "the old way" ;) Again I'm impressed by the speed how things are fixed in Postgres! Regards Thomas
Thomas Kellerer wrote: > Bruce Momjian, 06.10.2011 02:15: > >> I now got the same error (alas with a different relation id) while > >> migrating a completely different data directory. > >> > >> Anything I can do to help find the reason for this problem (or bug?) > >> > >> Unfortuantely the data contains some confidential information so I > >> cannot make it available. > > > > This bug was fixed just after 9.1.1 was released. The bug is that > > Windows doesn't properly pass the right flags for the oid set functions > > to operate. If you can compile the git 9.1.X current, the fix is in > > there; the fix will be in 9.1.2. > > > > Thanks for the feedback. > As those were only development databases, it was no big deal to do the migration "the old way" ;) > > Again I'm impressed by the speed how things are fixed in Postgres! Actually, this was one of our slow ones. :-) -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +