On 2015-01-30 09:29:59 -0500, Robert Haas wrote: > On Wed, Jan 14, 2015 at 9:03 PM, Andres Freund <and...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
