On 2021/10/06 17:14, bt21tanigaway wrote:
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.
Yes.
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.
I like this idea because it seems helpful at least for debug purpose.
・The purpose of this patch is to solve the delay problem, so I would like
another patch to deal with “ BackendPidGetProc” and “AuxiliaryPidGetProc”.
+1 to improve those things separately.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
