Re: Fix pg_log_backend_memory_contexts() 's delay
От | bt21tanigaway |
---|---|
Тема | Re: Fix pg_log_backend_memory_contexts() 's delay |
Дата | |
Msg-id | 1accf2ba3912f3f59a60ef90b5411433@oss.nttdata.com обсуждение исходный текст |
Ответ на | Re: Fix pg_log_backend_memory_contexts() 's delay (Michael Paquier <michael@paquier.xyz>) |
Ответы |
Re: Fix pg_log_backend_memory_contexts() 's delay
|
Список | pgsql-hackers |
Thanks for your review. >> Thanks for the patch. Do we also need to do the change in >> HandleMainLoopInterrupts, HandleCheckpointerInterrupts, >> HandlePgArchInterrupts, HandleWalWriterInterrupts as we don't call >> CHECK_FOR_INTERRUPTS() there? > Yeah, that's still some information that the user asked for. Looking > at the things that have a PGPROC entry, should we worry about the main > loop of the logical replication launcher? ・Now, the target of “pg_log_backend_memory_contexts()” is “autovacuum launcher” and “logical replication launcher”. I observed that the delay occurred only in “autovacuum launcher” not in “logical replication launcher”. ・”autovacuum launcher” used “HandleAutoVacLauncherInterrupts()” ( not including “ProcessLogMemoryContextInterrupt()” ) instead of “ProcessInterrupts() ( including “ProcessLogMemoryContextInterrupt()” ). “ProcessLogMemoryContextInterrupt()” will not be executed until the next “ProcessInterrupts()” is executed. So, I added “ProcessLogMemoryContextInterrupt()”. ・”logical replication launcher” uses only “ProcessInterrupts()”. So, We don’t have to fix it. > IMHO, we can support all the processes which return a PGPROC entry by > both BackendPidGetProc and AuxiliaryPidGetProc where the > AuxiliaryPidGetProc would cover the following processes. I'm not sure > one is interested in the memory context info of auxiliary processes. ・The purpose of this patch is to solve the delay problem, so I would like another patch to deal with “ BackendPidGetProc” and “AuxiliaryPidGetProc”. Regards, Koyu Tanigawa
В списке pgsql-hackers по дате отправления: