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

On Wed, Jan 14, 2015 at 9:03 PM, Andres Freund <andres(at)2ndquadrant(dot)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