2015-09-04 5:50 GMT+02:00 Shulgin, Oleksandr <oleksandr.shul...@zalando.de>:
> On Sep 3, 2015 10:14 PM, "Pavel Stehule" <pavel.steh...@gmail.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 >
