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

From Heikki Linnakangas
Subject Re: GiST insert algorithm rewrite
Date
Msg-id 4CF4CA04.3000003@enterprisedb.com
Whole thread Raw
In response to Re: GiST insert algorithm rewrite  (Bruce Momjian <bruce@momjian.us>)
Responses Re: GiST insert algorithm rewrite
List pgsql-hackers
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.

> You are saying it would have to be run before the upgrade.  Can it not
> be run after?

After would work too.

> I can output a script to VACUUM all such indexes, and tell users to
> manually REINDEX any index that generates a warning messasge.  I don't
> have any way to automate an optional REINDEX step.

That seems good enough.

--   Heikki Linnakangas  EnterpriseDB   http://www.enterprisedb.com


pgsql-hackers by date:

Previous
From: Dimitri Fontaine
Date:
Subject: Re: pg_execute_from_file review
Next
From: Heikki Linnakangas
Date:
Subject: Re: GiST insert algorithm rewrite