Re: cache lookup failed dropping public schema with trgm index

Поиск
Список
Период
Сортировка
От Wyatt Alt
Тема Re: cache lookup failed dropping public schema with trgm index
Дата
Msg-id CAGem3qBav_ydx-MiJ=Uo2a_sxLw5RY-VZ6qbfOw3bHynoLZDSQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: cache lookup failed dropping public schema with trgm index  (Michael Paquier <michael@paquier.xyz>)
Список 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

В списке pgsql-bugs по дате отправления:

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: cache lookup failed dropping public schema with trgm index
Следующее
От: Tom Lane
Дата:
Сообщение: Re: cache lookup failed dropping public schema with trgm index