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


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

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

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to