Skip site navigation (1) Skip section navigation (2)

Re: GiST insert algorithm rewrite

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Teodor Sigaev <teodor(at)sigaev(dot)ru>, Oleg Bartunov <oleg(at)sai(dot)msu(dot)su>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: GiST insert algorithm rewrite
Date: 2010-11-30 14:23:33
Message-ID: AANLkTikTi45ZHBxNej-t0iFGHdT-9PV8J-ed01u+bPq0@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
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

In response to

Responses

pgsql-hackers by date

Next:From: Csaba NagyDate: 2010-11-30 14:57:13
Subject: Re: DELETE with LIMIT (or my first hack)
Previous:From: Robert HaasDate: 2010-11-30 14:19:26
Subject: Re: DELETE with LIMIT (or my first hack)

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group