Brian Hirt <bh...@me.com> writes:
> 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?
Correct, you should just drop the ones that aren't in pg_catalog.
> 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.
That sure looks like a bug, but there's not enough info here to
diagnose. Is there actually a pg_toast.pg_toast_2147483647 table
in the 8.4 cluster? (I'm betting not.) Could you try extracting
a test case? I wonder whether "pg_dump -s" from the 8.4 database,
loaded into a fresh 8.4 database, would be enough to reproduce.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
