Re: GiST insert algorithm rewrite
От | Heikki Linnakangas |
---|---|
Тема | Re: GiST insert algorithm rewrite |
Дата | |
Msg-id | 4CF4CBCA.5070008@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: GiST insert algorithm rewrite (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>) |
Ответы |
Re: GiST insert algorithm rewrite
|
Список | pgsql-hackers |
On 30.11.2010 11:55, Heikki Linnakangas wrote: > 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. Oh sorry, I read your question as "9.0 *or* 9.1". Only GiST indexes that have any "invalid" tuples in them n, as a result of a crash, need to be reindexed. That's very rare in practice, so we shouldn't invalidate all GiST indexes. I don't think there's any simple way to check whether reindex is required, so I think we have to just document this. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: