Re: pg_upgrade

Looks like pg_upgrade is using 32bit oids.  2147483647 is the max signed 32 bit int, but the oids for my tables are
clearlylarger 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.relnamespaceand 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 <bhirt@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
tsearch2tables 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
themlater -- however, I'm confused about these tables in general, both pg_catalog.pg_ts_parser and public.pg_ts_parser
existwith different, albeit similar, schemas.   I think that the table in public is no longer used and was a remnant
frompre-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.
Iproceeded 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