Re: [ADMIN] pg_upgrade from 9.1.3 to 9.2 failed - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [ADMIN] pg_upgrade from 9.1.3 to 9.2 failed
Date
Msg-id 4512.1347851264@sss.pgh.pa.us
Whole thread Raw
In response to Re: [ADMIN] pg_upgrade from 9.1.3 to 9.2 failed  (Rural Hunter <ruralhunter@gmail.com>)
List pgsql-hackers
Rural Hunter <ruralhunter@gmail.com> writes:
> 于2012年9月17日 9:48:58,Tom Lane写到:
>> I wonder whether you dropped and recreated the information_schema in
>> the lifetime of this database?  We have recommended doing that in the
>> past, IIRC.  Could such a thing have confused pg_dump?

> No, I have never manually re-created the table.

I think you must have, because the query output shows that sql_features,
its rowtype, and the information_schema all have OIDs much larger than
they would have had in a virgin installation.  The large relfilenode
could have been explained by a VACUUM FULL, but the other OIDs wouldn't
have been changed by that.

> This is the first time 
> I see the name. But I'm not sure other things I installed before 
> recreated it or not, such as pg_buffercache etc. One more thing, is 
> this a hidden table? I can see it with '\d 
> information_schema.sql_features' but it's not in the list of '\d'.

That just means that information_schema is not in your search_path.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Rural Hunter
Date:
Subject: Re: [ADMIN] pg_upgrade from 9.1.3 to 9.2 failed
Next
From: Amit Kapila
Date:
Subject: Re: [WIP] Patch : Change pg_ident.conf parsing to be the same as pg_hba.conf