On 07/07/2026 16:46, torikoshia wrote:
> On 2026-07-06 22:05, Andrei Lepikhov wrote:
>>> 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.
Hmm, maybe I misunderstood the code in the standard_ExecutorRun:
/*
* Ensure LogQueryPlanPending is initialized in case there was no time for
* logging the plan. Otherwise plan will be logged at the next query
* execution on the same session.
*/
LogQueryPlanPending = false;
But here is kind of reproduction:
-- Session 1:
BEGIN;
SELECT pg_advisory_xact_lock(1);
-- Session 2:
SELECT pg_backend_pid();
BEGIN;
DECLARE c CURSOR FOR
SELECT pg_advisory_xact_lock(g) FROM generate_series(1, 5) g;
FETCH 1 FROM c;
-- Session 1:
SELECT pg_log_query_plan(:pid);
SELECT pg_sleep(1);
COMMIT;
-- Session 2:
FETCH 1 FROM c;
COMMIT;
I don't see any explain or other logging activity in the log. I wonder if
extended protocol faces the same problem.
So, it potentially makes sense to add a statistics field to the activity stat to
let users know whether the logging (and how many signals, if replace flag with a
counter) is awaiting execution.
Maybe it doesn't need to clean up the 'pending' flag at all if no query has been
executed yet - the query might be under planning, and the EXPLAIN will be logged
right at the beginning of execution.
--
regards, Andrei Lepikhov,
pgEdge
