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 по дате отправления:

Предыдущее
От: Florian Pflug
Дата:
Сообщение: Re: Range Types - typo + NULL string constructor
Следующее
От: Jeff Janes
Дата:
Сообщение: Re: COUNT(*) and index-only scans