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".
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...
best regards,
Florian Pflug