Re: GiST insert algorithm rewrite
От | Heikki Linnakangas |
---|---|
Тема | Re: GiST insert algorithm rewrite |
Дата | |
Msg-id | 4CF4CA04.3000003@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: GiST insert algorithm rewrite (Bruce Momjian <bruce@momjian.us>) |
Ответы |
Re: GiST insert algorithm rewrite
|
Список | pgsql-hackers |
On 27.11.2010 21:31, Bruce Momjian wrote: > Heikki Linnakangas wrote: >> There's no on-disk format changes, except for the additional flag in the >> page headers, so this does not affect pg_upgrade. However, if there's >> any "invalid" keys in the old index because of an incomplete insertion, >> the new code will not understand that. So you should run vacuum to >> ensure that there's no such invalid keys in the index before upgrading. >> Vacuum will print a message in the log if it finds any, and you will >> have to reindex. But that's what it suggests you to do anyway. > > OK, pg_upgrade has code to report invalid gin and hash indexes because > of changes between PG 8.3 and 8.4. Is this something we would do for > 9.0 to 9.1? 9.1. The problem that started this whole thing is there in older versions, but given the lack of real-life reports and the scale of the changes required it doesn't seem wise to backport. > You are saying it would have to be run before the upgrade. Can it not > be run after? After would work too. > I can output a script to VACUUM all such indexes, and tell users to > manually REINDEX any index that generates a warning messasge. I don't > have any way to automate an optional REINDEX step. That seems good enough. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: