Re: RFC: Logging plan of the running query
От | torikoshia |
---|---|
Тема | Re: RFC: Logging plan of the running query |
Дата | |
Msg-id | af8b4c4752dcee3ca7284e7c15922d5d@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 2023-06-16 01:34, James Coleman wrote: > Attached is v28 > which sets ProcessLogQueryPlanInterruptActive to false in errfinish > when necessary. Once built with those two patches I'm simply running > `make check`. With v28-0001 and v28-0002 patch, I confirmed backend processes consume huge amount of memory and under some environments they were terminated by OOM killer. This was because memory was allocated from existing memory contexts and they were not freed after ProcessLogQueryPlanInterrupt(). Updated the patch to use dedicated memory context for ProcessLogQueryPlanInterrupt(). Applying attached patch and v28-0002 patch, `make check` successfully completed after 20min and 50GB of logs on my environment. >>> On 2023-06-15 01:48, James Coleman wrote: >>> > The tests have been running since last night, but have been apparently >>> > hung now for many hours. I don't know if this has anything to do with the hung you faced, but I thought it might be possible that the large amount of memory usage resulted in swapping, which caused a significant delay in processing. If possible, I would be very grateful if you could try to reproduce this with the v29 patch. -- Regards, -- Atsushi Torikoshi NTT DATA CORPORATION
Вложения
В списке pgsql-hackers по дате отправления: