Re: GiST insert algorithm rewrite

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Cc: 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-27 19:31:31
Message-ID: 201011271931.oARJVV427882@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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?

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

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.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jeff Janes 2010-11-27 19:44:59 Re: contrib: auth_delay module
Previous Message Tom Lane 2010-11-27 19:27:12 Report: Linux huge pages with Postgres