Обсуждение: 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.

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