Re: Overhauling our interrupt handling (was Escaping from blocked send() reprised.)

On Wed, Jan 14, 2015 at 9:03 PM, Andres Freund <andres@2ndquadrant.com> wrote:
> 0002: Use a nonblocking socket for FE/BE communication and block using
>       latches.
>
>       Has previously been reviewed by Heikki. I think Noah also had a
>       look, although I'm not sure how close that was.
>
>       I think this can be committed soon.

Doesn't this significantly increase the number of system calls?  I
worry there could be a performance issue here.

> 0003: Introduce and use infrastructure for interrupt processing during client reads.
>
>       From here on ImmediateInterruptOK isn't set during client
>       communication. Normal interrupts and sinval/async interrupts are
>       processed outside of signal handlers. Especially the sinval/async
>       greatly simplify the respective code.

ProcessNotifyInterrupt() seems like it could lead to a failure to
respond to other interrupts if there is a sufficiently vigorous stream
of notify interrupts.  I think there ought to be one loop that goes
through and tries to handle each kind of interrupt in turn and then
loops until no interrupts remain.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company