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

On 2015-01-30 09:29:59 -0500, Robert Haas wrote:
> 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.

I've posted benchmarks upthread and I only could start to measure any
overhead in pretty absurd cases (i.e. several hundred connections on a
few core machine, all doing SELECT 1;statements). As we try
the read before the poll/select it's not that bad - there's no
superflous work done if we're actually busy.

> > 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.

That's nothing new though. It just used to be executed inside interrupts
directly, with looping. And we looped when enabling the notify
interrupts. Since I can't recall a report of this being problematic I'm
not that inclined to change even more than the patch already does. Given
that queuing notifies requires a lock I have a hard time seing this ever
fast enough to cause that problem.

Greetings,

Andres Freund

-- Andres Freund                       http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services