From: Tom Lane <tgl@sss.pgh.pa.us>
To: Karl Denninger <karl@denninger.net>
cc: pgsql-admin@lists.postgresql.org
Subject: Re: Upgrade failure attempting to go to 12.0
In-reply-to: <f2cf0a78-55d2-9d6b-8cc6-69a7d12e63f6@denninger.net>
References: <f2cf0a78-55d2-9d6b-8cc6-69a7d12e63f6@denninger.net>
Comments: In-reply-to Karl Denninger <karl@denninger.net>
	message dated "Tue, 22 Oct 2019 21:48:58 -0500"
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-ID: <28858.1571805488.1@sss.pgh.pa.us>
Content-Transfer-Encoding: 8bit
Date: Wed, 23 Oct 2019 00:38:08 -0400
Message-ID: <28859.1571805488@sss.pgh.pa.us>
Precedence: bulk

Karl Denninger <karl@denninger.net> writes:
> I think I've seen this before, but I can't figure out where the issue
> is.  The original database dates to way, way back when contrib/tsearch2
> was a loaded module instead of the functionality being part of the base
> system, and I suspect vestigal pieces are involved.

Yeah, that's what it looks like.  This:

> Command was: CREATE OPERATOR CLASS "public"."gist_tp_tsquery_ops"

is part of the old tsearch2 stuff, and you'll need to remove it from
the v10 installation before you can upgrade.

What I can't tell from this evidence is whether you'd ever converted
tsearch2 into an actual extension --- if you had, then "drop extension"
would be enough to get rid of it.  Otherwise, you need to consult a copy
of the old "uninstall_tsearch2.sql" script to find out what you ought to
get rid of.

If you have user tables or indexes that depend on the old tsearch2
objects, things get more complex :-( --- you'd want to update those
to depend on the newer core datatype and index opclasses before
you clean out the old ones.

			regards, tom lane