Re: Failed Assert in pgstat_assoc_relation - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Failed Assert in pgstat_assoc_relation
Date
Msg-id 640717.1669660636@sss.pgh.pa.us
Whole thread Raw
In response to Failed Assert in pgstat_assoc_relation  (vignesh C <vignesh21@gmail.com>)
Responses Re: Failed Assert in pgstat_assoc_relation
List 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 by date:

Previous
From: Robert Haas
Date:
Subject: Re: O(n) tasks cause lengthy startups and checkpoints
Next
From: Andres Freund
Date:
Subject: Re: Failed Assert in pgstat_assoc_relation