Re: RFC: Logging plan of the running query

From: torikoshia <torikoshia(at)oss(dot)nttdata(dot)com>
To: Hannu Krosing <hannuk(at)google(dot)com>
Cc: Atsushi Torikoshi <torikoshia(dot)tech(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, samimseih(at)gmail(dot)com, pgsql-hackers(at)lists(dot)postgresql(dot)org, destrex271(at)gmail(dot)com
Subject: Re: RFC: Logging plan of the running query
Date: 2025-04-30 09:53:40
Message-ID: 01962a4f656356fb2899a0c4ace83019@oss.nttdata.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 2025-04-28 08:55, Hannu Krosing wrote:
> Have you also checked out
> https://github.com/postgrespro/pg_query_state which logs running query
> plan AND collected counts and timings as a response to a signal?

Yes. For example, see the discussion:
https://www.postgresql.org/message-id/d68c3ae31672664876b22d2dcbb526d2%40postgrespro.ru

diff --git a/src/backend/tcop/postgres.c b/src/backend/tcop/postgres.c
index a750dc8..e1b0be5 100644
--- a/src/backend/tcop/postgres.c
+++ b/src/backend/tcop/postgres.c
@@ -3492,6 +3492,8 @@ ProcessInterrupts(void)
if (ParallelMessagePending)
HandleParallelMessages();

+ CheckAndHandleCustomSignals();

> Has this ever been discussed for inclusion in core ?

As far as I understand from reading a bit of pg_query_state, it
registers custom interrupts to obtain the query state, including the
output of EXPLAIN:

-- pg_query_state/patches/custom_signals_17.0.patch
diff --git a/src/backend/tcop/postgres.c b/src/backend/tcop/postgres.c
index a750dc8..e1b0be5 100644
--- a/src/backend/tcop/postgres.c
+++ b/src/backend/tcop/postgres.c
@@ -3492,6 +3492,8 @@ ProcessInterrupts(void)
if (ParallelMessagePending)
HandleParallelMessages();

+ CheckAndHandleCustomSignals();

However, we believe it is not safe to perform something as complex as
EXPLAIN during an interrupt.
For more details, please refer to the discussion below:
https://www.postgresql.org/message-id/CA%2BTgmobH%2BUto9MCD%2BvWc71bVbOnd7d8zeYjRT8nXaeLe5hsNJQ%40mail.gmail.com

Previous patches in this thread also attempted a similar approach, but
due to the safety concerns mentioned above, we decided to explore
alternative solutions.
As a result, we are currently proposing an approach based on wrapping
plan nodes instead.

--
Atsushi Torikoshi
Seconded from NTT DATA GROUP CORPORATION to SRA OSS K.K.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2025-04-30 10:14:26 Re: Enhancing Memory Context Statistics Reporting
Previous Message Zhijie Hou (Fujitsu) 2025-04-30 09:37:49 RE: Fix slot synchronization with two_phase decoding enabled