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”.
Iobserved 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
