pg_upgrade

From: Brian Hirt <bhirt(at)me(dot)com>
To: pgsql-general(at)postgresql(dot)org
Subject: pg_upgrade
Date: 2010-09-27 17:39:16
Message-ID: A45C531F-F9A7-42FB-B228-651373617CFC@me.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

I'm testing pg_upgrade out and ran into a couple of problems. First when I did pg_upgrade --check I got the tsearch2 tables preventing the upgrade from happening:

Database: testdatabase
public.pg_ts_dict.dict_init
public.pg_ts_dict.dict_lexize
public.pg_ts_parser.prs_start
public.pg_ts_parser.prs_nexttoken
public.pg_ts_parser.prs_end
public.pg_ts_parser.prs_headline
public.pg_ts_parser.prs_lextype

For testing, at this point I really didn't care about tsearch, so I simply dropped those tables so I could revisit them later -- however, I'm confused about these tables in general, both pg_catalog.pg_ts_parser and public.pg_ts_parser exist with different, albeit similar, schemas. I think that the table in public is no longer used and was a remnant from pre-8.3 when tsearch2 wasn't part of the distribution, can anyone confirm this?

Anyway, after removing the tsearch tables, I did pg_upgrade --check again and it said the clusters were compatible. I proceeded to run the upgrade command and it bombed out in the "Restoring user relation files" section. I've included some output below, any advice on what is going on? It seems something is messed up in either the check logic or actual migration code.

root(at)ubuntu:~# /usr/pg-8.4/bin/oid2name
All databases:
Oid Database Name Tablespace
-------------------------------------------
...
11564 postgres pg_default
...
root(at)ubuntu:~# /usr/pg-8.4/bin/oid2name -o 2683
>From database "postgres":
Filenode Table Name
----------------------------------------
2683 pg_largeobject_loid_pn_index

postgres(at)ubuntu:~$ /usr/pg-9.0/bin/pg_upgrade
Performing Consistency Checks
-----------------------------
Checking old data directory (/moby/pgdb-8.4) ok
Checking old bin directory (/usr/pg-8.4/bin) ok
Checking new data directory (/moby/pgdb-9.0) ok
Checking new bin directory (/usr/pg-9.0/bin) ok
Checking for reg* system oid user data types ok
Checking for /contrib/isn with bigint-passing mismatch ok
Checking for large objects ok
Creating catalog dump 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 /moby/pgdb-8.4/global/pg_control.old.

Performing Migration
--------------------
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 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 ok
Removing support functions from new cluster ok
Restoring user relation files
/moby/pgdb-8.4/base/11564/2683
Could not find pg_toast.pg_toast_2147483647 in new cluster

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Igor Neyman 2010-09-27 17:56:53 Re: Preserving order through an inner join
Previous Message Grzegorz Jaśkiewicz 2010-09-27 15:16:12 Re: Deleting orphaned records (not exists is very slow)