On 2026-07-06 22:05, Andrei Lepikhov wrote:
On 06/07/2026 08:21, torikoshia wrote:
On Wed, Jul 1, 2026 at 7:42 PM Andrei Lepikhov <[email protected]>
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.
I doubt the performance impact, but generally agree: having
ExecSetExecProcNode/ExecProcNodeFirst trick with a one-time callback
inside
(right now it is the only hard-wired LogQueryPlan call) may be enough
for the
implementation.
So, the extendable part here may be an ExecProcNodeFirst callback that
an
extension module can register once (for example, before the start of an
EXPLAIN
ANALYZE) or re-arm on each call of such 'execution state probes'.
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.
That's the problem.
Sorry, I misremembered the logic.
In this case, even if execution moves to an external or deeper
QueryDesc, LogQueryPlanPending flag remains set. Therefore, the plan
tree for that external or deeper QueryDesc will be wrapped, and
the plan will be logged.
For example, with the following query, ExecProcNode() is called four
times:
CREATE OR REPLACE FUNCTION f1() RETURNS void AS $$
BEGIN
PERFORM 1;
END;
$$ LANGUAGE plpgsql;
SELECT f1();
If pg_log_query_plan() is called just after the first
ExecProcNode() call reaches ExecProcNodeFirst(), the plan for PERFORM 1
is logged.
Thanks,
--
Atsushi Torikoshi
Seconded from NTT DATA CORPORATION to SRA OSS K.K.
