On Thu, Oct 3, 2013 at 05:24:49PM -0400, Bruce Momjian wrote:
> On Thu, Oct 3, 2013 at 02:48:20PM -0400, Robert Haas wrote:
> > On Thu, Oct 3, 2013 at 2:43 PM, Heikki Linnakangas
> > <hlinnakangas@vmware.com> wrote:
> > > It seems we've all but decided that we'll require reindexing GIN indexes in
> > > 9.4.
> >
> > I thought the consensus in Ottawa was strongly against that. I'm not
> > aware that anyone has subsequently changed their position on the
> > topic. Bruce is right to point out that we've done such things before
> > and can therefore do it again, but just because we have the technical
> > means to do it doesn't make it good policy.
> >
> > That having been said, if we do decide to break it...
>
> Agreed. I was stating only that this is easy for pg_upgrade. One cool
> thing is that the upgrades completes, and the indexes are there, but
> just marked as invalid until the REINDEX.
>
> One other point Alexander made is that the new GIN indexes will be
> smaller so most people would want the new format in the new cluster
> anyway.
I am in Moscow with Alexander and we were discussing GIN pg_upgrade
issues. One option we have already discussed was to take the old GIN
index code and put it in a separate directory, and call the new GIN
index something different, but that got hung up on how users were going
to create indexes of the new type.
One nice trick would be for the index creation code to check the global
variable IsBinaryUpgrade that pg_upgrade sets. If CREATE INDEX ... GIN
finds IsBinaryUpgrade set, it should create an (empty) index of type
gin-v1/old. If it is not set, it should create a new gin index. This
will allow pg_upgrade to work, and allow REINDEX to create a new-type
GIN index from an old one.
We would need to append "-v1" to the old index directory, system
catalog, and function names. We could then remove the old GIN index
code in some later major release, and pg_upgrade will then mark the
indexes as invalid and create a REINDEX script.
This allows users to reindex their GIN indexes over time, but it doesn't
lock us into keeping the gin-v1 code around forever.
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ Everyone has their own god. +
