Re: Failed Assert in pgstat_assoc_relation
Andres Freund <andres@anarazel.de>
From: Andres Freund <andres@anarazel.de>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: vignesh C <vignesh21@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2022-11-28T21:09:08Z
Lists: pgsql-hackers
Attachments
- relcache_assoc.diff (text/x-diff) patch
Hi, On 2022-11-28 10:50:13 -0800, Andres Freund wrote: > On 2022-11-28 13:37:16 -0500, Tom Lane wrote: > > 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? Something like the attached. Still needs a bit of polish, e.g. adding the test case from above. I'm a bit uncomfortable adding a function call below * Perform swapping of the relcache entry contents. Within this * process the old entry is momentarily invalid, so there *must* be no * possibility of CHECK_FOR_INTERRUPTS within this sequence. Do it in * all-in-line code for safety. but it's not the first, see MemoryContextSetParent(). Greetings, Andres Freund
Commits
-
Prevent pgstats from getting confused when relkind of a relation changes
- af3517c15c84 11.19 landed
- 35b99a18f5fb 12.14 landed
- 7944d2d8c78b 13.10 landed
- cb2e7ddfe571 16.0 landed
- 6344bc0974dc 14.7 landed
- c6a60471a1a5 15.2 landed
-
Remove logic for converting a table to a view.
- b23cd185fd54 16.0 landed