On Sat, Oct 19, 2013 at 05:11:55PM -0400, Bruce Momjian wrote:
> 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.

Correction --- the above is not going to work because the backend isn't
going to know, during a binary upgrade, if CREATE INDEX ... GIN is
coming from a 9.3 or 9.4 database.  We are going to need pg_dump code to
do the mapping, and also pg_dump code to map gin_v1 back to gin once we
remove the gin_v1 code.  We will also need index creation code to map
gin_v1 to gin to properly handle REINDEX and CLUSTER, but only if not in
binary upgrade mode.

If it would help, I would be happy to write a simple patch for the above
items once I return from Europe in November.

  Bruce Momjian  <br...@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + Everyone has their own god. +

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

Reply via email to