Re: On-demand running query plans using auto_explain and signals

2015-09-04 5:50 GMT+02:00 Shulgin, Oleksandr <oleksandr(dot)shulgin(at)zalando(dot)de>:

> On Sep 3, 2015 10:14 PM, "Pavel Stehule" <pavel(dot)stehule(at)gmail(dot)com> wrote:
> >>>
> >>> Please find attached a v3.
> >>>
> >>> It uses a shared memory queue and also has the ability to capture
> plans nested deeply in the call stack. Not sure about using the executor
> hook, since this is not an extension...
> >>>
> >>> The LWLock is used around initializing/cleaning the shared struct and
> the message queue, the IO synchronization is handled by the message queue
> itself.
> >>
> >> I am not pretty happy from this design. Only one EXPLAIN PID/GET STATUS
> in one time can be executed per server - I remember lot of queries that
> doesn't handle CANCEL well ~ doesn't handle interrupt well, and this can be
> unfriendly. Cannot to say if it is good enough for first iteration. This is
> functionality that can be used for diagnostic when you have overloaded
> server and this risk looks too high (for me). The idea of receive slot can
> to solve this risk well (and can be used elsewhere). The difference from
> this code should not be too big - although it is not trivial - needs work
> with PGPROC. The opinion of our multiprocess experts can be interesting.
> Maybe I am too careful.
>
> Sorry, but I still don't see how the slots help this issue - could you
> please elaborate?
>
with slot (or some similiar) there is not global locked resource. If I'll
have a time at weekend I'll try to write some prototype.

> >> Other smaller issues:
> >>
> >> * probably sending line by line is useless - shm_mq_send can pass
> bigger data when nowait = false
>
> I'm not sending it like that because of the message size - I just find it
> more convenient. If you think it can be problematic, its easy to do this as
> before, by splitting lines on the receiving side.
>
Yes, shm queue sending data immediately - so slicing on sender generates
more interprocess communication

> >> * pg_usleep(1000L); - it is related to single point resource
>
> But not a highly concurrent one.
>
I believe so it is not becessary - waiting (sleeping) can be deeper in
reading from queue - the code will be cleaner

Regard

Pavel

> -
> Alex
>