Обсуждение: pg_upgrade from 18beta1 -> 18beta3 - problem with btree_gist contrib module / extension
pg_upgrade from 18beta1 -> 18beta3 - problem with btree_gist contrib module / extension
От
Achilleas Mantzios
Дата:
pg_restore: from TOC entry 4295; 1255 596569951 FUNCTION gist_stratnum_btree(integer) postgres
pg_restore: error: could not execute query: ERROR: could not find function "gist_stratnum_btree" in file "/usr/local/pgsql/lib/btree_gist.so"
Command was: CREATE FUNCTION "public"."gist_stratnum_btree"(integer) RETURNS smallint
LANGUAGE "c" IMMUTABLE STRICT PARALLEL SAFE
AS '$libdir/btree_gist', 'gist_stratnum_btree';
The solution was to somehow restart 18beta1, drop btree_gist and all its dependent constraints / indexes / objects , pg_upgrade and finally re-create extension and dependent objects.
Re: pg_upgrade from 18beta1 -> 18beta3 - problem with btree_gist contrib module / extension
От
Adrian Klaver
Дата:
On 8/20/25 05:50, Achilleas Mantzios wrote: > pg_restore: from TOC entry 4295; 1255 596569951 FUNCTION > gist_stratnum_btree(integer) postgres > pg_restore: error: could not execute query: ERROR: could not find > function "gist_stratnum_btree" in file "/usr/local/pgsql/lib/btree_gist.so" > Command was: CREATE FUNCTION "public"."gist_stratnum_btree"(integer) > RETURNS smallint > LANGUAGE "c" IMMUTABLE STRICT PARALLEL SAFE > AS '$libdir/btree_gist', 'gist_stratnum_btree'; I can not find gist_stratnum_btree in: https://www.postgresql.org/docs/18/btree-gist.html or in the source. How did it end up in the database? > > > The solution was to somehow restart 18beta1, drop btree_gist and all its > dependent constraints / indexes / objects , pg_upgrade and finally re- > create extension and dependent objects. > Something more then DROP EXTENSION/CREATE EXTENSION btree_gist? -- Adrian Klaver adrian.klaver@aklaver.com
Re: pg_upgrade from 18beta1 -> 18beta3 - problem with btree_gist contrib module / extension
От
Paul A Jungwirth
Дата:
On Wed, Aug 20, 2025 at 9:39 AM Adrian Klaver <adrian.klaver@aklaver.com> wrote: > > On 8/20/25 05:50, Achilleas Mantzios wrote: > > pg_restore: from TOC entry 4295; 1255 596569951 FUNCTION > > gist_stratnum_btree(integer) postgres > > pg_restore: error: could not execute query: ERROR: could not find > > function "gist_stratnum_btree" in file "/usr/local/pgsql/lib/btree_gist.so" > > Command was: CREATE FUNCTION "public"."gist_stratnum_btree"(integer) > > RETURNS smallint > > LANGUAGE "c" IMMUTABLE STRICT PARALLEL SAFE > > AS '$libdir/btree_gist', 'gist_stratnum_btree'; > > I can not find gist_stratnum_btree in: > > https://www.postgresql.org/docs/18/btree-gist.html > > or in the source. > > How did it end up in the database? gist_stratnum_btree was in beta1 but was renamed to gist_translate_cmptype_btree by 32edf732e8dc9eb3e7a923aeb67d49246744a20a. > > The solution was to somehow restart 18beta1, drop btree_gist and all its > > dependent constraints / indexes / objects , pg_upgrade and finally re- > > create extension and dependent objects. > > Something more then DROP EXTENSION/CREATE EXTENSION btree_gist? That seems like the easiest fix to me. But if you've built indexes based on those opclasses then more work is required, as here. I don't know what pg_upgrade tries to support for moving from one beta release to another. Is this something we should try to fix? Yours, -- Paul ~{:-) pj@illuminatedcomputing.com
Adrian Klaver <adrian.klaver@aklaver.com> writes: > I can not find gist_stratnum_btree in: > https://www.postgresql.org/docs/18/btree-gist.html > or in the source. > How did it end up in the database? See commit 32edf732e. Perhaps that renaming should not have been done post-beta1, but that's where we are. regards, tom lane
Paul A Jungwirth <pj@illuminatedcomputing.com> writes: > I don't know what pg_upgrade tries to support for moving from one beta > release to another. Is this something we should try to fix? It's water over the dam now, I think. If we had such a breakage between officially-released versions, that would be bad enough to justify jumping through hoops. But beta releases have always been "use at your own risk". regards, tom lane