On 12/18/2012 02:34 PM, Tom Lane wrote:
> 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.
>
>
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