Re: GIN improvements part 1: additional information

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Alexander Korotkov <aekorotkov(at)gmail(dot)com>
Cc: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: GIN improvements part 1: additional information
Date: 2013-09-23 15:35:54
Message-ID: 20130923153554.GA9534@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, Sep 15, 2013 at 01:14:45PM +0400, Alexander Korotkov wrote:
> On Sat, Jun 29, 2013 at 12:56 PM, Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>
> wrote:
>
> There's a few open questions:
>
> 1. How are we going to handle pg_upgrade? It would be nice to be able to
> read the old page format, or convert on-the-fly. OTOH, if it gets too
> complicated, might not be worth it. The indexes are much smaller with the
> patch, so anyone using GIN probably wants to rebuild them anyway, sooner or
> later. Still, I'd like to give it a shot.

We have broken pg_upgrade index compatibility in the past.
Specifically, hash and GIN index binary format changed from PG 8.3 to
8.4. I handled it by invalidating the indexes and providing a
post-upgrade script to REINDEX all the changed indexes. The user
message is:

Your installation contains hash and/or GIN indexes. These indexes have
different internal formats between your old and new clusters, so they
must be reindexed with the REINDEX command. The file:

...

when executed by psql by the database superuser will recreate all invalid
indexes; until then, none of these indexes will be used.

It would be very easy to do this from a pg_upgrade perspective.
However, I know there has been complaints from others about making
pg_upgrade more restrictive.

In this specific case, even if you write code to read the old file
format, we might want to create the REINDEX script to allow _optional_
reindexing to shrink the index files.

If we do require the REINDEX, --check will clearly warn the user that
this will be required.

--
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 Andrew Dunstan 2013-09-23 15:43:13 Re: PostgreSQL 9.3 beta breaks some extensions "make install"
Previous Message Alvaro Herrera 2013-09-23 15:31:40 Re: PostgreSQL 9.3 beta breaks some extensions "make install"