Re: Failed Assert in pgstat_assoc_relation
От | Andres Freund |
---|---|
Тема | Re: Failed Assert in pgstat_assoc_relation |
Дата | |
Msg-id | 20221128210908.hyffmljjylj447nu@awork3.anarazel.de обсуждение исходный текст |
Ответ на | Re: Failed Assert in pgstat_assoc_relation (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: Failed Assert in pgstat_assoc_relation
|
Список | pgsql-hackers |
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
Вложения
В списке pgsql-hackers по дате отправления: