Re: GiST insert algorithm rewrite

On Tue, Nov 30, 2010 at 5:02 AM, Heikki Linnakangas
<heikki(dot)linnakangas(at)enterprisedb(dot)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