Re: cache lookup failed dropping public schema with trgm index

Wyatt Alt <wyatt.alt@gmail.com>

From: Wyatt Alt <wyatt.alt@gmail.com>
To: Michael Paquier <michael@paquier.xyz>
Cc: Andres Freund <andres@anarazel.de>, pgsql-bugs@lists.postgresql.org
Date: 2023-08-21T23:13:57Z
Lists: pgsql-bugs
Thanks for having a look. Note also that switching the first two lines of
my example prevents the failure.

On Mon, Aug 21, 2023 at 3:55 PM Michael Paquier <michael@paquier.xyz> wrote:

> On Mon, Aug 21, 2023 at 03:36:10PM -0700, Andres Freund wrote:
> > It also seems to work without even involving a drop schema. Just dropping
> > pg_trgm with cascade is sufficient.
>
> FWIW, after a bisect I can see that 911e7020 is the origin of the
> failure (`git bisect start b5d69b7 9e1c9f9` based on two merge-bases).
>
> > Now, this isn't a real issue in practice (without such a debugging
> statement,
> > which likely can't work in some cases), but I strongly suspect that it
> > indicates a scheduling order issue that's more widespread. Despite, I
> think,
> > correct dependencies, we end up with a topologically inconsistent drop
> > order. There aren't any cycles in the directed dependency graph from
> what I
> > can see.
>
> Yeah, guess so.  I was first betting on a missing shared inval here.
> Now note that for example, this command works:
> psql -v ON_ERROR_STOP=1 -c 'create table foo(t text); create extension
> pg_trgm; create index on foo using gist(t gist_trgm_ops);create index on
> foo using gist(t gist_trgm_ops); drop schema public cascade;'
> --
> Michael
>