Re: Bug in walsender when calling out to do_pg_stop_backup (and others?) - Mailing list pgsql-hackers

From Magnus Hagander
Subject Re: Bug in walsender when calling out to do_pg_stop_backup (and others?)
Date
Msg-id CABUevEwBEgLJovHyhHcvXV5gj=OojscJBDfJxFuvn3M0FkMyqw@mail.gmail.com
Whole thread Raw
In response to Re: Bug in walsender when calling out to do_pg_stop_backup (and others?)  (Florian Pflug <fgp@phlo.org>)
Responses Re: Bug in walsender when calling out to do_pg_stop_backup (and others?)
List pgsql-hackers
On Tue, Oct 11, 2011 at 03:29, Florian Pflug <fgp@phlo.org> wrote:
> On Oct10, 2011, at 21:25 , Magnus Hagander wrote:
>> On Thu, Oct 6, 2011 at 23:46, Florian Pflug <fgp@phlo.org> wrote:
>>> It'd be nice to generally terminate a backend if the client vanishes, but so
>>> far I haven't had any bright ideas. Using FASYNC and F_SETOWN unfortunately
>>> sends a signal *everytime* the fd becomes readable or writeable, not only on
>>> EOF. Doing select() in CHECK_FOR_INTERRUPTS seems far too expensive. We could
>>> make the postmaster keep the fd's of around even after forking a backend, and
>>> make it watch for broken connections using select(). But with a large max_backends
>>> settings, we'd risk running out of fds in the postmaster...
>>
>> Ugh. Yeah. But at least catching it and terminating it when we *do*
>> notice it's down would certainly make sense...
>
> I'll try to put together a patch that sets a flag if we discover a broken
> connection in pq_flush, and tests that flag in CHECK_FOR_INTERRUPTS. Unless you
> wanna, of course.

Please do, I won't have time to even think about it until after
pgconf.eu anyway ;)


--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/


pgsql-hackers by date:

Previous
From: jesper@krogh.cc
Date:
Subject: Re: COUNT(*) and index-only scans
Next
From: Thom Brown
Date:
Subject: Re: Range Types - typo + NULL string constructor