John Rogers <John@delosis.com> writes:
> surely postgres should stop the select if the client
> dissapears in a puff of smoke?
The current design intention is that the backend will notice loss of
connection when it next tries to receive a command from the client
--- and not before. You could argue that a SELECT is side-effect
free and can be aborted arbitrarily, but I wouldn't agree, because
the SELECT could be invoking a user-defined function that does have
side effects. If we were to abort upon noticing that the output data
didn't seem to be going anywhere, then the behavior would be both
timing-dependent and platform-dependent.
> ... we end up with a postgres SELECT thread running at 99% cpu
> time on our backend.
If the SELECT is taking more CPU than it otherwise would, then that
might represent a bug we oughta fix. But I don't think that finishing
out a requested SELECT is in and of itself a bug.
regards, tom lane
