Re: GiST insert algorithm rewrite - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: GiST insert algorithm rewrite
Date
Msg-id 4CF4CBCA.5070008@enterprisedb.com
Whole thread Raw
In response to Re: GiST insert algorithm rewrite  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Responses Re: GiST insert algorithm rewrite
List 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 by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: GiST insert algorithm rewrite
Next
From: Itagaki Takahiro
Date:
Subject: Re: Tab completion for view triggers in psql