Re: RFC: Logging plan of the running query
От | torikoshia |
---|---|
Тема | Re: RFC: Logging plan of the running query |
Дата | |
Msg-id | 379d69c0b3d058997550f88e73ffddd6@oss.nttdata.com обсуждение исходный текст |
Ответ на | Re: RFC: Logging plan of the running query (torikoshia <torikoshia@oss.nttdata.com>) |
Ответы |
Re: RFC: Logging plan of the running query
|
Список | pgsql-hackers |
On 2022-03-09 19:04, torikoshia wrote: > On 2022-02-08 01:13, Fujii Masao wrote: >> AbortSubTransaction() should reset ActiveQueryDesc to >> save_ActiveQueryDesc that ExecutorRun() set, instead of NULL? >> Otherwise ActiveQueryDesc of top-level statement will be unavailable >> after subtransaction is aborted in the nested statements. > > I once agreed above suggestion and made v20 patch making > save_ActiveQueryDesc a global variable, but it caused segfault when > calling pg_log_query_plan() after FreeQueryDesc(). > > OTOH, doing some kind of reset of ActiveQueryDesc seems necessary > since it also caused segfault when running pg_log_query_plan() during > installcheck. > > There may be a better way, but resetting ActiveQueryDesc to NULL seems > safe and simple. > Of course it makes pg_log_query_plan() useless after a subtransaction > is aborted. > However, if it does not often happen that people want to know the > running query's plan whose subtransaction is aborted, resetting > ActiveQueryDesc to NULL would be acceptable. > > Attached is a patch that sets ActiveQueryDesc to NULL when a > subtransaction is aborted. > > How do you think? Attached new patch to fix patch apply failures. -- Regards, -- Atsushi Torikoshi NTT DATA CORPORATION
Вложения
В списке pgsql-hackers по дате отправления: