Re: Failed Assert in pgstat_assoc_relation

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Failed Assert in pgstat_assoc_relation
Дата
Msg-id 640717.1669660636@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Failed Assert in pgstat_assoc_relation  (vignesh C <vignesh21@gmail.com>)
Ответы Re: Failed Assert in pgstat_assoc_relation  (Andres Freund <andres@anarazel.de>)
Список pgsql-hackers
vignesh C <vignesh21@gmail.com> writes:
> I could reproduce this issue with the following steps:
> create table t1(c int);
> BEGIN;
> CREATE TABLE t (c int);
> SAVEPOINT q;
> CREATE RULE "_RETURN" AS ON SELECT TO t DO INSTEAD  SELECT * FROM t1;
> select * from t;
> ROLLBACK TO q;
> CREATE RULE "_RETURN" AS ON SELECT TO t DO INSTEAD  SELECT * FROM t1;
> ROLLBACK;

Uh-huh.  I've not bothered to trace this in detail, but presumably
what is happening is that the first CREATE RULE converts the table
to a view, and then the ROLLBACK undoes that so far as the catalogs
are concerned, but probably doesn't undo related pg_stats state
changes fully.  Then we're in a bad state that will cause problems.
(It still crashes if you replace the second CREATE RULE with
"select * from t".)

As far as HEAD is concerned, maybe it's time to nuke the whole
convert-table-to-view kluge entirely?  Only pg_dump older than
9.4 will emit such code, so we're really about out of reasons
to keep on maintaining it.

However, I'm not sure that removing that code in v15 will fly,
so maybe we need to make the new pg_stats code a little more
robust against the possibility of a relkind change.

            regards, tom lane



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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: O(n) tasks cause lengthy startups and checkpoints
Следующее
От: Andres Freund
Дата:
Сообщение: Re: Failed Assert in pgstat_assoc_relation