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.


Reply via email to