Horton
Menu

Re: RFC: Logging plan of the running query

Andrei Lepikhov <lepihov@gmail.com>

View thread
From: Andrei Lepikhov <lepihov@gmail.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: torikoshia <torikoshia@oss.nttdata.com>, Lukas Fittl <lukas@fittl.com>, pgsql-hackers@lists.postgresql.org, Atsushi Torikoshi <torikoshia.tech@gmail.com>, samimseih@gmail.com, destrex271@gmail.com
Date: 2026-06-25T10:33:14Z
Lists: pgsql-hackers 
On 25/06/2026 11:43, Robert Haas wrote:
> On Wed, Jun 24, 2026 at 10:35 AM Andrei Lepikhov <lepihov@gmail.com> wrote:
>> 1. pg_log_query_plan - This function just sends a signal. There are no
>> guarantees that actual action will be performed. So, the 'request' word makes
>> more sense for me.
> 
> I don't agree with this particular comment. Of course nothing is
> absolutely guaranteed because the database system could crash or the
> world could end, but if the target backend is running a query, it
> should log the query plan. Therefore, I don't see the need for a word
> like "request".
> 

Ok, so just mention this behaviour in the documentation - let people know that
they should potentially wait for a minute or two more to see the EXPLAIN.
Real-life with huge queries and big machines provide us with examples where a
backend might delay a response to a signal for quite a substantial time.

Sometimes nothing happens after such an async operation, and we need to identify
the problem: has the backend stalled, is the ‘logging plan’ algorithm
ineffective, or is something else happening?

-- 
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.