Re: [WIP] Patches to enable extraction state of query execution from external session
От | Maksim Milyutin |
---|---|
Тема | Re: [WIP] Patches to enable extraction state of query execution from external session |
Дата | |
Msg-id | b692e2d0-d4ef-99cb-f299-5efd7d3373f7@postgrespro.ru обсуждение исходный текст |
Ответ на | Re: [WIP] Patches to enable extraction state of query execution from external session (Oleksandr Shulgin <oleksandr.shulgin@zalando.de>) |
Ответы |
Re: [WIP] Patches to enable extraction state of query
execution from external session
|
Список | pgsql-hackers |
> 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
В списке pgsql-hackers по дате отправления: