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

Поиск
Список
Период
Сортировка
От Oleksandr Shulgin
Тема Re: [WIP] Patches to enable extraction state of query execution from external session
Дата
Msg-id CACACo5Rhdnnsy6c1QyMQywPWkUpwR-S+k8WQrMH3YUeKFtkNew@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [WIP] Patches to enable extraction state of query execution from external session  (Maksim Milyutin <m.milyutin@postgrespro.ru>)
Ответы Re: [WIP] Patches to enable extraction state of query execution from external session  (Maksim Milyutin <m.milyutin@postgrespro.ru>)
Список pgsql-hackers
On Tue, Aug 30, 2016 at 9:34 AM, Maksim Milyutin <m.milyutin@postgrespro.ru> wrote:
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.

Yes, but the problem is that nothing gives you the guarantee that at the moment you decide to handle the interrupt, the QueryDesc structures you're looking at are in a good shape for Explain* functions to run on them.  Even if that appears to be the case in your testing now, there's no way to tell if that will be the case at any future point in time.

Another problem is use if shm_mq facility, because it manipulates the state of process latch.  This is not supposed to happen to a backend happily performing its tasks, at random due to external factors, and this is what the proposed approach introduces.

--
Alex

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: PostgreSQL 10 kick-off
Следующее
От: Tom Lane
Дата:
Сообщение: Re: new gcc warning