Horton
Menu

Re: RFC: Logging plan of the running query

Robert Haas <robertmhaas@gmail.com>

View thread
From: Robert Haas <robertmhaas@gmail.com>
To: Andrei Lepikhov <lepihov@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-25T09:43:50Z
Lists: pgsql-hackers 
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".

-- 
Robert Haas
EDB: http://www.enterprisedb.com

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.