2015-09-08 18:53 GMT+02:00 Shulgin, Oleksandr <oleksandr.shul...@zalando.de> :
> On Tue, Sep 8, 2015 at 11:49 AM, Shulgin, Oleksandr < > oleksandr.shul...@zalando.de> wrote: > >> >> >> The real problem could be if the process that was signaled to connect >> to the message queue never handles the interrupt, and we keep waiting >> forever in shm_mq_receive(). We could add a timeout parameter or just let >> the user cancel the call: send a cancellation request, use >> pg_cancel_backend() or set statement_timeout before running this. >> > >> > This is valid question - for begin we can use a statement_timeout and >> we don't need to design some special (if you don't hold some important >> lock). >> > My example (the code has prototype quality) is little bit longer, but >> it work without global lock - the requester doesn't block any other >> >> I'll update the commitfest patch to use this technique. >> > > Please find attached v4. > It is better Two notices: 1. The communication mechanism can be used more wide, than only for this purpose. We can introduce a SendInfoHook - and it can be used for any customer probes - memory, cpu, ... 2. With your support for explain of nested queries we have all what we need for integration auto_explain to core. Regards Pavel > > -- > Alex > >
