Looks like pg_upgrade is using 32bit oids. 2147483647 is the max signed 32 bit
int, but the oids for my tables are clearly larger than that.
== output from pg_upgrade ==
Database: basement84_dev
relname: mit.company: reloid: 2147483647 reltblspace:
relname: mit.company_history: reloid: 2147483647 reltblspace:
== output from catalog query ==
basement84_dev=# select c.oid,c.relname from pg_catalog.pg_namespace n,
pg_catalog.pg_class c where n.oid = c.relnamespace and n.nspname = 'mit';
oid | relname
------------+--------------------
3000767630 | company
3000767633 | company_history
(22 rows)
On Sep 28, 2010, at 10:51 AM, Tom Lane wrote:
> 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
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
