On Thu, Oct 6, 2011 at 23:46, Florian Pflug <fgp@phlo.org> wrote:
> On Oct6, 2011, at 21:48 , Magnus Hagander wrote:
>>> The question is, should we do more? To me, it'd make sense to terminate
>>> a backend once it's connection is gone. We could, for example, make
>>> pq_flush() set a global flag, and make CHECK_FOR_INTERRUPTS handle a
>>> broken connection that same way as a SIGINT or SIGTERM.
>>
>> The problem here is that we're hanging at a place where we don't touch
>> the socket. So we won't notice the socket is gone. We'd have to do a
>> select() or something like that at regular intervals to make sure it's
>> there, no?
>
> We do emit NOTICEs saying "pg_stop_backup still waiting ... " repeatedly,
> so we should notice a dead connection sooner or later. When I tried, I even
> got a message in the log complaining about the "broken pipe".
Ah, good point, that should be doable. Forgot about that message...
> As it stands, the interval between two NOTICEs grows exponentially - we
> send the first after waiting 5 second, the next after waiting 60 seconds,
> and then after waiting 120, 240, 480, ... seconds. This means that that the
> backend would in the worst case linger the same amount of time *after*
> pg_basebackup was cancelled that pg_basebackup waited for *before* it was
> cancelled.
>
> 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...
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/