From: | Andres Freund <andres(at)2ndquadrant(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp> |
Subject: | Re: Overhauling our interrupt handling (was Escaping from blocked send() reprised.) |
Date: | 2015-01-30 15:13:49 |
Message-ID: | 20150130151349.GJ24213@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Kevin Grittner | 2015-01-30 15:19:40 | Re: pg_dump with both --serializable-deferrable and -j |
Previous Message | Geoff Winkless | 2015-01-30 14:59:12 | Re: INSERT ... ON CONFLICT {UPDATE | IGNORE} 2.0 |