Re: Feature freeze date for 8.1

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> I was under the impression that the specific scenario is
> busy-in-transaction backends continuing to produce and send data while
> the client has disappeared. Why does the backend ignore network errors
> and keep sending data?

There are a couple of reasons behind that:

1. In terms of resources held against the rest of the database,
a query doing SELECT is hardly likely to be your worst problem.
Queries doing UPDATE, VACUUM, etc are holding stronger locks and
probably chewing at least as many resources; but they aren't doing
any client I/O (until the command tag at the very end) and so are
not going to detect client connection loss significantly earlier
than they do now anyway.

2. Because of the lack of output, the behavior of non-SELECT queries
is that they complete before the backend notices client connection
loss. This is nice because it makes it simpler to reason about what
will happen. Currently the backend guarantees the same for SELECT
queries, which is also nice, since we have plenty of SELECT queries
with side-effects (consider user function invocation). Do we really
want to give that up?

3. If we error out on send() failure then we have turned a probable
failure into certain failure, because we will have lost message-boundary
sync with the client --- in other words the error might as well be a
FATAL one. This seems like it might be overkill.

4. Erroring out in the low-level routines is trickier than it looks;
in particular, after you elog() your complaint, elog.c is going to
come right back to you with an error message to send to the client.
Not having this turn into an infinite recursion is a bit ticklish.
Making sure it stays working is even trickier, considering what a
seldom-tested code path it's going to be.

regards, tom lane