Prevent pgstats from getting confused when relkind of a relation changes
authorAndres Freund <[email protected]>
Sat, 3 Dec 2022 02:09:55 +0000 (18:09 -0800)
committerAndres Freund <[email protected]>
Sat, 3 Dec 2022 02:10:30 +0000 (18:10 -0800)
When the relkind of a relache entry changes, because a table is converted into
a view, pgstats can get confused in 15+, leading to crashes or assertion
failures.

For HEAD, Tom fixed this in b23cd185fd5, by removing support for converting a
table to a view, removing the source of the inconsistency. This commit just
adds an assertion that a relcache entry's relkind does not change, just in
case we end up with another case of that in the future. As there's no cases of
changing relkind anymore, we can't add a test that that's handled correctly.

For 15, fix the problem by not maintaining the association with the old pgstat
entry when the relkind changes during a relcache invalidation processing. In
that case the pgstat entry needs to be unlinked first, to avoid
PgStat_TableStatus->relation getting out of sync. Also add a test reproducing
the issues.

No known problem exists in 11-14, so just add the test there.

Reported-by: vignesh C <[email protected]>
Author: Andres Freund <[email protected]>
Reviewed-by: Tom Lane <[email protected]>
Discussion: https://postgr.es/m/CALDaNm2yXz+zOtv7y5zBd5WKT8O0Ld3YxikuU3dcyCvxF7gypA@mail.gmail.com
Discussion: https://postgr.es/m/CALDaNm3oZA-8Wbps2Jd1g5_Gjrr-x3YWrJPek-mF5Asrrvz2Dg@mail.gmail.com
Backpatch: 15-

src/backend/utils/cache/relcache.c

index bd6cd4e47b508e3ff1fcfbc3a965f31c65057440..a50eecc7c8a4c0bfee51c09fcd2fed2d77e9ed2f 100644 (file)
@@ -2661,6 +2661,13 @@ RelationClearRelation(Relation relation, bool rebuild)
                        elog(ERROR, "relation %u deleted while still in use", save_relid);
                }
 
+               /*
+                * If we were to, again, have cases of the relkind of a relcache entry
+                * changing, we would need to ensure that pgstats does not get
+                * confused.
+                */
+               Assert(relation->rd_rel->relkind == newrel->rd_rel->relkind);
+
                keep_tupdesc = equalTupleDescs(relation->rd_att, newrel->rd_att);
                keep_rules = equalRuleLocks(relation->rd_rules, newrel->rd_rules);
                keep_policies = equalRSDesc(relation->rd_rsdesc, newrel->rd_rsdesc);