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 28666.1347833056@sss.pgh.pa.us
Whole thread Raw
In response to Re: [ADMIN] pg_upgrade from 9.1.3 to 9.2 failed  (Bruce Momjian <bruce@momjian.us>)
Responses Re: [ADMIN] pg_upgrade from 9.1.3 to 9.2 failed  (Bruce Momjian <bruce@momjian.us>)
List pgsql-hackers
Bruce Momjian <bruce@momjian.us> writes:
> On Sun, Sep 16, 2012 at 12:38:37PM +0800, Rural Hunter wrote:
>> I ran the pg_upgrade with the patch and found the problematic object
>> is a toast object.

> OK, this is exactly what I wanted to see, and it explains why pg_dump
> didn't show it.  Can you find out what table references this toast
> table?  Try this query on the old cluster:

>     select oid, * from pg_class WHERE reltoastrelid = 16439148;

> I believe it will have an oid of 16439145, or it might not exist.

Most likely what's happened is that the table has a toast table that
it doesn't need, as a result of having dropped the only wide column(s)
in it.  So when the table is recreated in the new cluster, there's no
toast table for it.

So what you need to do is get rid of that check, or relax it so that it
doesn't insist on toast tables matching up exactly.  It seems possible
that there could be discrepancies in the other direction too, ie,
new cluster created a toast table when old cluster didn't have one.
        regards, tom lane



pgsql-hackers by date:

Previous
From: "Kevin Grittner"
Date:
Subject: Re: Question about SSI, subxacts, and aborted read-only xacts
Next
From: Andres Freund
Date:
Subject: Add pg_relation_by_filenode(reltbspc, filenode) admin function