Re: RFC: Logging plan of the running query
torikoshia <torikoshia@oss.nttdata.com>
From: torikoshia <torikoshia@oss.nttdata.com>
To: Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>,
masao.fujii@oss.nttdata.com
Cc: Dilip Kumar <dilipbalaut@gmail.com>, Pgsql Hackers
<pgsql-hackers@postgresql.org>
Date: 2021-06-22T02:30:31Z
Lists: pgsql-hackers
Attachments
- v4-0001-log-running-query-plan.patch (text/x-diff) patch v4-0001
On 2021-06-16 20:36, torikoshia wrote: >> other background or parallel worker. > > As far as I looked around, there seems no easy ways to do so. > >> If we were to invent a new >> mechanism just for addressing the above comment, I would rather choose >> to not do that as it seems like an overkill. We can leave it up to the >> user whether or not to unnecessarily signal those processes which are >> bound to print "PID XXX is not executing queries now" message. > > +1. I'm going to proceed in this direction. Updated the patch. On Thu, Jun 10, 2021 at 11:09 AM torikoshia <torikoshia@oss.nttdata.com> wrote: > On 2021-06-09 23:04, Fujii Masao wrote: > > 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 haven't found a proper way yet but it seems necessary to use something other than ActivePortal and I'm now thinking this could be a separate patch in the future. -- Regards, -- Atsushi Torikoshi NTT DATA CORPORATION
Commits
-
Allow GRANT on pg_log_backend_memory_contexts().
- f0b051e322d5 15.0 cited