Re: Fix pg_log_backend_memory_contexts() 's delay

From: bt21tanigaway <bt21tanigaway(at)oss(dot)nttdata(dot)com>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Fix pg_log_backend_memory_contexts() 's delay
Date: 2021-10-06 08:14:51
Message-ID: 1accf2ba3912f3f59a60ef90b5411433@oss.nttdata.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2021-10-06 08:24:29 Re: More business with $Test::Builder::Level in the TAP tests
Previous Message Masahiko Sawada 2021-10-06 07:10:50 Parallel vacuum workers prevent the oldest xmin from advancing