Skip site navigation (1) Skip section navigation (2)

Re: pg_upgrade

From: Brian Hirt <bhirt(at)me(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: pg_upgrade
Date: 2010-09-28 19:30:49
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-general
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: 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 <bhirt(at)me(dot)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(at)postgresql(dot)org)
> To make changes to your subscription:

In response to


pgsql-general by date

Next:From: Chris BarnesDate: 2010-09-28 19:48:00
Subject: Autovacuum settings between systems
Previous:From: Igor NeymanDate: 2010-09-28 19:13:34
Subject: Re: Scaling PostgreSQL-9

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group