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

On Thu, Sep 17, 2015 at 5:16 PM, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
wrote:

> 2015-09-17 16:46 GMT+02:00 Robert Haas <robertmhaas(at)gmail(dot)com>:
>
>>
>> Second, using a shm_mq manipulates the state of the process latch. I
>> don't think you can make the assumption that it's safe to reset the
>> process latch at any and every place where we check for interrupts.
>> For example, suppose the process is already using a shm_mq and the
>> CHECK_FOR_INTERRUPTS() call inside that code then discovers that
>> somebody has activated this mechanism and you now go try to send and
>> receive from a new shm_mq. But even if that and every other
>> CHECK_FOR_INTERRUPTS() in the code can tolerate a process latch reset
>> today, it's a new coding rule that could easily trip people up in the
>> future.
>>
>
> It is valid, and probably most important. But if we introduce own
> mechanism, we will play with process latch too (although we can use LWlocks)
>

Careful manipulation of the process latch is a valid point. Probably we
were way too optimistic about the limits we can hit with this approach. :-(

But if we make the sender backend create the DSM with the response payload,
it suddenly becomes really unclear at which point and who should make the
final detach of that DSM. We're getting back to the problem of
synchronization between these processes all over again.

--
Alex