Horton
Menu

Re: RFC: Logging plan of the running query

Andrei Lepikhov <lepihov@gmail.com>

View thread
From: Andrei Lepikhov <lepihov@gmail.com>
To: torikoshia <torikoshia@oss.nttdata.com>
Cc: Lukas Fittl <lukas@fittl.com>, Robert Haas <robertmhaas@gmail.com>, pgsql-hackers@lists.postgresql.org, Atsushi Torikoshi <torikoshia.tech@gmail.com>, samimseih@gmail.com, destrex271@gmail.com
Date: 2026-07-02T11:05:57Z
Lists: pgsql-hackers 
On 01/07/2026 15:09, torikoshia wrote:
> Thanks for the comments!
> I will mainly consider the 3rd and 4th points.
Thanks,

I read the EXPLAIN generation part of the code. It looks good.

It prepares a clean EXPLAIN that’s good for stability and safety, because the
hardest part of the task has been correctly gathering the instrumentation for
the partially executed query: interrupting parallel workers and merging their
instrumentation is always the pain.

Also, it leaves room for extensions or future development if the user wants to
make a hard stop and take a full picture of the current state, including rows,
buffers, WAL, and whatever is possible with current instrumentation.

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.

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

-- 
regards, Andrei Lepikhov,
pgEdge

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. ecpg: Catch zero-length Unicode identifiers correctly

  2. Improve warning message in pg_signal_backend()

  3. Add assert to ensure that page locks don't participate in deadlock cycle.