Andres Freund <andres@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.
regards, tom lane