Re: [ADMIN] pg_upgrade from 9.1.3 to 9.2 failed

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Rural Hunter <ruralhunter(at)gmail(dot)com>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [ADMIN] pg_upgrade from 9.1.3 to 9.2 failed
Date: 2012-09-17 03:07:44
Message-ID: 4512.1347851264@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin pgsql-hackers

Rural Hunter <ruralhunter(at)gmail(dot)com> writes:
> 2012917 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

In response to

Browse pgsql-admin by date

  From Date Subject
Next Message Bruce Momjian 2012-09-17 04:32:36 Re: [ADMIN] pg_upgrade from 9.1.3 to 9.2 failed
Previous Message Rural Hunter 2012-09-17 01:56:13 Re: [ADMIN] pg_upgrade from 9.1.3 to 9.2 failed

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2012-09-17 03:37:24 Re: [WIP] Patch : Change pg_ident.conf parsing to be the same as pg_hba.conf
Previous Message Rural Hunter 2012-09-17 01:56:13 Re: [ADMIN] pg_upgrade from 9.1.3 to 9.2 failed