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.
