From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Karl Denninger <karl(at)denninger(dot)net> |
Cc: | pgsql-admin(at)lists(dot)postgresql(dot)org |
Subject: | Re: Upgrade failure attempting to go to 12.0 |
Date: | 2019-10-23 04:38:08 |
Message-ID: | 28859.1571805488@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
Karl Denninger <karl(at)denninger(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Setve | 2019-10-27 20:23:01 | the difference between psql , createdb, dropuser |
Previous Message | Karl Denninger | 2019-10-23 02:48:58 | Upgrade failure attempting to go to 12.0 |