Re: RFC: Logging plan of the running query

On Wed, Jul 1, 2026 at 7:42 PM Andrei Lepikhov <lepihov(at)gmail(dot)com>
wrote:

> I’d
> propose introducing a tiny hook (register callback?) into
> ExecProcNode() and
> just setting it in ProcessLogQueryPlanInterrupt.

This approach would also be possible, but we are concerned that
checking the hook on every ExecProcNode() call would add too much
overhead and could have a significant performance impact.

This point was discussed previously:
https://www.postgresql.org/message-id/20240215185911.v4o6fo444md6a3w7%40awork3.anarazel.de

> 4. Also, I’m not sure it is safe to store the QueryDesc pointer at all
> at the
> ProcessLogQueryPlanInterrupt.

I think the current implementation does not store a pointer to the
queryDesc passed to ProcessLogQueryPlanInterrupt().
That queryDesc is used only to obtain the PlanState nodes that need
to be wrapped. For plan logging itself, LogQueryPlan() uses a
queryDesc obtained separately.

> Maybe the next call to ExecProcNode() will be made
> from an external query (or from a deeper one).
> The current implementation will
> not produce any EXPLAIN in this case, but query still executes.

That said, I think a similar situation can still occur if execution
moves to an external or deeper queryDesc after the individual plan
nodes have been wrapped. In that case, the plan does not be logged
even though the query continues executing.

> I think, combination of a global hook and queryDesc pointer, saved
> somewhere in
> the EState may solve the problem. It is available at each executor's
> node, and
> the EXPLAIN machinery might use an exact descriptor related to the
> currently
> executing query.

Given the performance concern mentioned above, my impression was that
using a global hook would not be a viable approach.

Even if we could address that point, I suspect it would still be
difficult to eliminate this kind of issue entirely, because signal
handling through CFI() and wrapping plan nodes and its execution are
asynchronous.

My understanding is that this problem can occur only when the next
ExecProcNode() call after wrapping the plan nodes happens to be
for an inner or external query.

So personally, I hope it might be acceptable to treat this as a
case where the backend did not reach a point at which the plan
could be logged, as described in the documentation change below:

+ The plan is logged when the target backend next reaches a
+ point where the running plan can be inspected. (..snip..)
+ If the query finishes before such a point is
+ reached, no plan may be logged.

> 5. The phrase ‘only the plan of the most deeply nested query is logged’
> is
> missed in the docs. So the current decision has not yet been
> documented.

Added the explanation:

+ If the target backend is executing a nested query when it
+ processes the request, only the plan of the innermost
+ executing query is logged.

On Thu, Jul 2, 2026 at 8:06 PM Andrei Lepikhov <lepihov(at)gmail(dot)com>
wrote:
> The only 'es→signaled' flag is an eyesore. It would be better to base
> the
> decision on the es→analyze flag, which would break the long-standing
> auto_explain rule, if I understand correctly. So, at least this flag
> should be
> renamed to something like es→running, or es→query_in_progress.

Modified to es->running.

> Also, not sure I understand how this code regulates the explain format,
> verbosity and other EXPLAIN settings.

As discussed in the following thread, the current implementation uses
the default
EXPLAIN options and does not provide any particular way to regulate
them:
https://www.postgresql.org/message-id/57ee0cf0cf76b742b0144bd481c56b57%40oss.nttdata.com

As mentioned in that discussion, I think it would be possible to make
this configurable
in the future, for example by adding GUCs or by adding options to
pg_log_query_plan().
For now, however, I would like to focus on developing the mechanism for
obtaining the
plan of a currently running query.

Thanks,

--
Atsushi Torikoshi
Seconded from NTT DATA CORPORATION to SRA OSS K.K.