On Tue, Nov 30, 2010 at 5:02 AM, Heikki Linnakangas <heikki.linnakan...@enterprisedb.com> wrote: > 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.
It seems odd to say, the indexes are corrupted, but they're probably not, so let's not worry about it. I assume there's no way to make the new code cope with any pre-existing corruption? Does the current code cope with the corruption? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
