Re: [ADMIN] Problems with enums after pg_upgrade
От | Tom Lane |
---|---|
Тема | Re: [ADMIN] Problems with enums after pg_upgrade |
Дата | |
Msg-id | 12773.1355859273@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [ADMIN] Problems with enums after pg_upgrade (Andres Freund <andres@2ndquadrant.com>) |
Ответы |
Re: [ADMIN] Problems with enums after pg_upgrade
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: