Re: [PATCH] fix wait_event of pg_stat_activity in case of high amount of connections
От | Kyotaro Horiguchi |
---|---|
Тема | Re: [PATCH] fix wait_event of pg_stat_activity in case of high amount of connections |
Дата | |
Msg-id | 20220708.113925.694736747577500484.horikyota.ntt@gmail.com обсуждение исходный текст |
Ответ на | Re: [PATCH] fix wait_event of pg_stat_activity in case of high amount of connections (Justin Pryzby <pryzby@telsasoft.com>) |
Ответы |
Re: [PATCH] fix wait_event of pg_stat_activity in case of high amount of connections
|
Список | pgsql-hackers |
At Thu, 7 Jul 2022 13:58:06 -0500, Justin Pryzby <pryzby@telsasoft.com> wrote in > I agree that this is a bug, since it can (and did) cause false positives in a > monitoring system. I'm not this is undoubtfully a bug but agree about the rest. > > As well, patch changes way to allocate memory for local structure. Before it > > estimates maximum size of required memory and allocate it at once. It could > > result into allocation of dozens/hundreds of megabytes for nothing. Now it > > allocates memory by chunks to reduce overall amount of allocated memory and > > reduce time for allocation. > > I suggest to present this as two patches: a 0001 patch to fix the bug, and > proposed for backpatch, and an 0002 patch for master to improve memory usage. > As attached. Actually, once 0001 is resolved, it may be good to start a > separate thread for 0002. I plan to add to the next CF. Looking the patch 0001, I wonder we can move wait_even_info from PGPROC to backend status. If I'm not missing anything, I don't see a plausible requirement for it being in PROC, or rather see a reason to move it to backend_status. > void > pgstat_report_activity(BackendState state, const char *cmd_str) > { > ... > beentry->st_xact_start_timestamp = 0; > beentry->st_query_id = UINT64CONST(0); > proc->wait_event_info = 0; > PGSTAT_END_WRITE_ACTIVITY(beentry); regards. -- Kyotaro Horiguchi NTT Open Source Software Center
В списке pgsql-hackers по дате отправления: