Hi, On 2022-11-28 13:37:16 -0500, Tom Lane wrote: > vignesh C <vignes...@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".)
Yea. I haven't yet fully traced through this, but presumably relcache inval doesn't fix this because we don't want to loose pending stats after DDL. Perhaps we need to add a rule about not swapping pgstat* in RelationClearRelation() when relkind changes? > 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. Sounds good to me. > However, I'm not sure that removing that code in v15 will fly, Agreed, at the very least that'd increase memory usage. > so maybe we need to make the new pg_stats code a little more > robust against the possibility of a relkind change. Possibly via the relcache code. Greetings, Andres Freund
