Re: Bug in walsender when calling out to do_pg_stop_backup (and others?)
От | Florian Pflug |
---|---|
Тема | Re: Bug in walsender when calling out to do_pg_stop_backup (and others?) |
Дата | |
Msg-id | 62112E7E-8F02-41BD-879F-39959A692372@phlo.org обсуждение исходный текст |
Ответ на | Re: Bug in walsender when calling out to do_pg_stop_backup (and others?) (Magnus Hagander <magnus@hagander.net>) |
Ответы |
Re: Bug in walsender when calling out to do_pg_stop_backup
(and others?)
|
Список | pgsql-hackers |
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. best regards, Florian Pflug
В списке pgsql-hackers по дате отправления: