On 12/18/2012 02:34 PM, Tom Lane wrote:
Andres Freund <and...@2ndquadrant.com> writes:
On 2012-12-18 13:24:12 -0500, Tom Lane wrote:
Does the table being updated have any indexes on enum columns? I'm
suspicious that the bogus OID is in an index page somewhere, and not
in the table at all.
I already wondered whether it could be a problem caused by pg_upgrade
not ignoring invalid indexes until recently, but I don't really see how
it could cause an invalid oid to end up in the index.
It seems like this might indicate a flaw in our scheme for preventing
uncommitted enum values from getting into tables/indexes. Hard to see
what though.
Bernhard, if you do identify a particular index as being the source of
the failure, that would at least tell us for sure which enum type is
at fault. I don't suppose you would have any info about the history
of that enum type in your database? The fact that the OID is odd
implies that it belonged to a value that was added by ALTER TYPE ADD
VALUE, but what we'd want is some context around any past uses of
that command, especially if they failed or were rolled back.
He's upgrading from 9.0, which didn't have enum extension at all, and
where odd enums didn't mean anything special.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
