Re: Using ProcSignal to get memory context stats from a running backend

On 22 December 2017 at 23:19, Maksim Milyutin <milyutinma(at)gmail(dot)com> wrote:

> On 22.12.2017 16:56, Craig Ringer wrote:
>
> On 22 December 2017 at 20:50, Maksim Milyutin <milyutinma(at)gmail(dot)com>
> wrote:
>
>> On 19.12.2017 16:54, Pavel Stehule wrote:
>>
>> sorry for small offtopic. Can be used this mechanism for log of executed
>> plan or full query?
>>
>>
> That's a really good idea. I'd love to be able to pg_explain_backend(...)
>
> I left the mechanism as a generic diagnostic signal exactly so that we
> could add other things we wanted to be able to ask backends. I think a
> follow-on patch that adds support for dumping explain-format plans would be
> great, if it's practical to do that while a query's already running.
>
>
> Noticing the interest in the calling some routines on the remote backend
> through signals, in parallel thread[1] I have proposed the possibility to
> define user defined signal handlers in extensions. There is a patch taken
> from pg_query_state module.
>
> 1. https://www.postgresql.org/message-id/3f905f10-cf7a-d4e0-
> 64a1-7fd9b8351592%40gmail.com
>
>
Haven't read the patch, but the idea seems useful if a bit hairy in
practice. It'd be done on a "use at your own risk, and if it breaks you get
to keep the pieces" basis, where no guarantees are made by Pg about how and
when the function is called so it must be utterly defensive. The challenge
there being that you can't always learn enough about the state of the
system without doing things that might break it, so lots of things you
could do would be fragile.

--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services