From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | Wyatt Alt <wyatt(dot)alt(at)gmail(dot)com>, pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: cache lookup failed dropping public schema with trgm index |
Date: | 2023-08-21 22:55:28 |
Message-ID: | ZOPrYNyJO95YItPp@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Wyatt Alt | 2023-08-21 23:13:57 | Re: cache lookup failed dropping public schema with trgm index |
Previous Message | Andres Freund | 2023-08-21 22:36:10 | Re: cache lookup failed dropping public schema with trgm index |