> On Mon, Aug 29, 2016 at 5:22 PM, maksim <m.milyutin@postgrespro.ru
> <mailto:m.milyutin@postgrespro.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
