Re: Fix pg_log_backend_memory_contexts() 's delay

From: Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>
To: bt21tanigaway <bt21tanigaway(at)oss(dot)nttdata(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Fix pg_log_backend_memory_contexts() 's delay
Date: 2021-10-05 10:35:04
Message-ID: CALj2ACVpGVeZw6OO8yeROcn9347kbEppph5Pc1WzJJx3EjXNyg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Oct 5, 2021 at 2:50 PM bt21tanigaway
<bt21tanigaway(at)oss(dot)nttdata(dot)com> wrote:
>
> Hi,
>
> Log output takes time between several seconds to a few tens when using
> ‘SELECT pg_log_backend_memory_contexts(1234)’ with PID of ‘autovacuum
> launcher’.
> I made a patch for this problem.

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? And there are also other processes:
pgstat process/statistics collector, syslogger, walreceiver,
walsender, background workers, parallel workers and so on. I think we
need to change in all the processes where we don't call
CHECK_FOR_INTERRUPTS() in their main loops.

Before doing that, we need to be sure of whether we allow only the
user sessions/backend process's memory contexts with
pg_log_backend_memory_contexts or any process that is forked by
postmaster i.e. auxiliary process? The function
pg_log_backend_memory_contexts supports the processes that return a
pgproc structure from this function BackendPidGetProc, it doesn't
attempt to get pgproc structure from AuxiliaryPidGetProc.

Regards,
Bharath Rupireddy.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2021-10-05 10:38:02 Re: Next Steps with Hash Indexes
Previous Message Dagfinn Ilmari Mannsåker 2021-10-05 09:59:02 Re: plperl: update ppport.h and fix configure version check