Date: Mon, 23 Sep 2013 11:35:54 -0400
From: Bruce Momjian <bruce@momjian.us>
To: Alexander Korotkov <aekorotkov@gmail.com>
Cc: Heikki Linnakangas <hlinnakangas@vmware.com>,
 pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: GIN improvements part 1: additional information
Message-ID: <20130923153554.GA9534@momjian.us>
References: 
 <CAPpHfduxv-iL7aedwPW0W5fXrWGAKfxijWM63_hZujaCRxnmFQ@mail.gmail.com>
 <CAPpHfduQrtC4B+MC9_z3QB8oJsK1Ws-H8ivEsy_cmDnfoJqkeQ@mail.gmail.com>
 <CAPpHfdszEJhSynTPX6=tB3aKq1EA1JXpwx4xiFYM097K7PhQLA@mail.gmail.com>
 <CAPpHfdu8=5spaS7c9mxwH7bNMDR6n378fZCv6c2Y3YM7iE5KiQ@mail.gmail.com>
 <51CEA13C.8040103@vmware.com>
 <CAPpHfdutJEC9+6vWX579afZKzdHKCT2wzDkAEom1XmiXEwF3pw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
 <CAPpHfdutJEC9+6vWX579afZKzdHKCT2wzDkAEom1XmiXEwF3pw@mail.gmail.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

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@vmware.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@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

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


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers