Re: [ADMIN] Problems with enums after pg_upgrade
От | Tom Lane |
---|---|
Тема | Re: [ADMIN] Problems with enums after pg_upgrade |
Дата | |
Msg-id | 9230.1355863093@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [ADMIN] Problems with enums after pg_upgrade (Andrew Dunstan <andrew@dunslane.net>) |
Ответы |
Re: [ADMIN] Problems with enums after pg_upgrade
|
Список | pgsql-hackers |
Andrew Dunstan <andrew@dunslane.net> writes: > People have been known to hack pg_enum on their own, especially before > we added enum extension. > Of course, if they do that they get to keep both pieces. Yeah ... this would be very readily explainable if there had been a manual deletion from pg_enum somewhere along the line. Even if there were at that time no instances of the OID left in tables, there could be some in upper btree pages. They'd have caused no trouble in 9.0 but would (if odd) cause trouble in 9.2. Of course, this theory doesn't explain why the problem was seen on some copies and not others cloned from the same database --- unless maybe there had been an index page split on the master in between the clonings, and that moved the troublesome OID into a position where it was more likely to get compared-to. That's not a hugely convincing explanation though. regards, tom lane
В списке pgsql-hackers по дате отправления: