Re: [ADMIN] Problems with enums after pg_upgrade
| От | Andrew Dunstan |
|---|---|
| Тема | Re: [ADMIN] Problems with enums after pg_upgrade |
| Дата | |
| Msg-id | 50D0C80D.90806@dunslane.net обсуждение исходный текст |
| Ответ на | Re: [ADMIN] Problems with enums after pg_upgrade (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: [ADMIN] Problems with enums after pg_upgrade
|
| Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: