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

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