Pavel Stehule <pavel.stehule@gmail.com> writes:
> I prefer simple solution without any "intelligence". It is much safer to
> close connect and rollback. Then it is clean protocol - when server didn't
> reported successful end of operation, then operation was reverted - always.
It would be a fatal mistake to imagine that this feature would offer any
greater guarantees in that line than we have today (which is to say,
none really). It can be no better than the OS network stack's error
detection/reporting, which is necessarily pretty weak. The fact that
the kernel accepted a "command complete" message from us doesn't mean
that the client was still alive at that instant, much less that the
message will be deliverable.
In general I think the threshold problem for a patch like this will be
"how do you keep the added overhead down". As Robert noted upthread,
timeout.c is quite a bit shy of being able to handle timeouts that
persist across statements. I don't think that there's any fundamental
reason it can't be improved, but it will need improvements.
regards, tom lane
