On Wed, Feb 19, 2014 at 06:37:42PM -0500, Tom Lane wrote: > Emre Hasegeli <e...@hasegeli.com> writes: > > [ cites bug #5705 ] > > Hm. I had forgotten how thoroughly broken btree_gist's inet and cidr > opclasses are. There was discussion at the time of just ripping them > out despite the compatibility hit. We didn't do it, but if we had > then life would be simpler now. > > Perhaps it would be acceptable to drop the btree_gist implementation > and teach pg_upgrade to refuse to upgrade if the old database contains > any such indexes. I'm not sure that solves the problem, though, because > I think pg_upgrade will still fail if the opclass is in the old database > even though unused (because you'll get the complaint about multiple > default opclasses anyway). The only simple way to avoid that is to not > have btree_gist loaded at all in the old DB, and I doubt that's an > acceptable upgrade restriction. It would require dropping indexes of > the other types supported by btree_gist, which would be a pretty hard > sell since those aren't broken. > > Really what we'd need here is for btree_gist to be upgraded to a version > that doesn't define gist_inet_ops (or at least doesn't mark it as default) > *before* pg_upgrading to a server version containing the proposed new > implementation. Not sure how workable that is. Could we get away with > having pg_upgrade unset the default flag in the old database? > (Ick, but there are no very good alternatives here ...)
pg_upgrade has _never_ modified the old cluster, and I am hesitant to do that now. Can we make the changes in the new cluster, or in pg_dump when in binary upgrade mode? -- 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
