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: http://www.postgresql.org/mailpref/pgsql-hackers
