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

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?

>> 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.

>> * pg_usleep(1000L); - it is related to single point resource

But not a highly concurrent one.

-
Alex