Re: RFC: Logging plan of the running query

From: torikoshia <torikoshia(at)oss(dot)nttdata(dot)com>
To: Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com>, Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: RFC: Logging plan of the running query
Date: 2021-06-10 02:09:22
Message-ID: 7a122c0ab3347c2097cee49a2757742a@oss.nttdata.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2021-06-09 23:04, Fujii Masao wrote:

Thanks for your review!

> auto_explain can log the plan of even nested statement
> if auto_explain.log_nested_statements is enabled.
> But ISTM that pg_log_current_plan() cannot log that plan.
> Is this intentional?

> I think that it's better to make pg_log_current_plan() log
> the plan of even nested statement.

+1. It would be better.
But currently plan information is got from ActivePortal and ISTM there
are no easy way to retrieve plan information of nested statements from
ActivePortal.
Anyway I'll do some more research.

I think you are right about the following comments.
I'll fix them.

> + es->format = EXPLAIN_FORMAT_TEXT;
> + es->settings = true;
>
> Since pg_log_current_plan() is usually used to investigate and
> trouble-shoot the long running queries, IMO it's better to
> enable es->verbose by default and get additional information
> about the queries. Thought?
> + * pg_log_current_plan
> + * Signal a backend process to log plan the of running query.
>
> "plan the of" is typo?
>
>
> + * Only superusers are allowed to signal to log plan because any users
> to
> + * issue this request at an unbounded rate would cause lots of log
> messages
> + * and which can lead to denial of service.
>
> "because any users" should be "because allowing any users"
> like the comment for pg_log_backend_memory_contexts()?
>
>
> + * All the actual work is deferred to ProcessLogExplainInterrupt(),
>
> "ProcessLogExplainInterrupt()" should be
> "ProcessLogCurrentPlanInterrupt()"?
>
> Regards,

--
Regards,

--
Atsushi Torikoshi
NTT DATA CORPORATION

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2021-06-10 02:09:52 Re: Move pg_attribute.attcompression to earlier in struct for reduced size?
Previous Message Kyotaro Horiguchi 2021-06-10 02:04:20 Re: Transactions involving multiple postgres foreign servers, take 2