Re: [WIP] Patches to enable extraction state of query execution from external session

From: Maksim Milyutin <m(dot)milyutin(at)postgrespro(dot)ru>
To: Oleksandr Shulgin <oleksandr(dot)shulgin(at)zalando(dot)de>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [WIP] Patches to enable extraction state of query execution from external session
Date: 2016-08-30 07:34:43
Message-ID: b692e2d0-d4ef-99cb-f299-5efd7d3373f7@postgrespro.ru
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> On Mon, Aug 29, 2016 at 5:22 PM, maksim <m(dot)milyutin(at)postgrespro(dot)ru
> <mailto:m(dot)milyutin(at)postgrespro(dot)ru>> wrote:
>
> Hi, hackers!
>
> Now I complete extension that provides facility to see the current
> state of query execution working on external session in form of
> EXPLAIN ANALYZE output. This extension works on 9.5 version, for 9.6
> and later it doesn't support detailed statistics for parallel nodes yet.
>
> I want to present patches to the latest version of PostgreSQL core
> to enable this extension.
>
> Hello,
>
> Did you publish the extension itself yet?
>

Hello, extension for version 9.5 is available in repository
https://github.com/postgrespro/pg_query_state/tree/master.

> Last year (actually, exactly one year ago) I was trying to do something
> very similar, and it quickly turned out that signals are not the best
> way to make this sort of inspection. You can find the discussion
> here: https://www.postgresql.org/message-id/CACACo5Sz7G0MFauC082iM=XX_hQ7qQ5ndR4JPo+H-O5vp6iCcQ@mail.gmail.com

Thanks for link!

My patch *custom_signal.patch* resolves the problem of «heavy» signal
handlers. In essence, I follow the course offered in *procsignal.c*
file. They define *ProcSignalReason* values on which the SUGUSR1 is
multiplexed. Signal recent causes setting flags for *ProcessInterrupt*
actuating, i.e. procsignal_sigusr1_handler() only sets specific flags.
When CHECK_FOR_INTERRUPTS appears later on query execution
*ProcessInterrupt* is called. Then triggered user defined signal handler
is executed.
As a result, we have a deferred signal handling.

Patch *runtime_explain.patch* releases the problem with error from
InstrEndLoop(). I catch all places where this unlucky function is called
and wrap in checks on *runtime* flag. This flag indicates whether
*ExplainQuery* is called for running query. Also I complement explain
output, you can see details in README.md in repository.

--
Maksim Milyutin
Postgres Professional: http://www.postgrespro.com
Russian Postgres Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Fujii Masao 2016-08-30 07:49:30 Re: GIN logging GIN_SEGMENT_UNMODIFIED actions?
Previous Message Dean Rasheed 2016-08-30 07:05:15 Re: RLS related docs