On Tue, Oct 11, 2011 at 03:29, Florian Pflug <f...@phlo.org> wrote: > On Oct10, 2011, at 21:25 , Magnus Hagander wrote: >> On Thu, Oct 6, 2011 at 23:46, Florian Pflug <f...@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/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
