Neil Conway <neilc@samurai.com> writes:
>> Does anyone have comments on that email?
> I wouldn't be opposed to it. It would be different than
> statement_timeout, in that we'd be measuring transaction *idle* time,
We would? Why? Please provide a motivation that justifies the
considerably higher cost to make it count that way, as opposed to
time-since-BEGIN. If the point is to limit the time for which locks
are held, I should think this would actually be *less* desirable than
constraining time-since-BEGIN.
> Also, presumably when the
> transaction idle timeout fires, we should just rollback the current
> transaction, not close the client connection
Certainly ...
> -- so you could potentially
> have idle backends sticking around for the full TCP timeout period.
... but that doesn't necessarily follow. Once we've been motivated to
try to send an error message to the client, the relevant timeouts are
way shorter than they are under connection-idle conditions.
> Since they shouldn't be holding any locks I don't see that as a big problem.
Right, once we've released the transaction the pain grows greatly less.
We are still occupying a backend slot though, so failing sooner has some
value, if there is no doubt the connection is unrecoverable. (But see
my upthread doubts about whether we know that better than the TCP stack
does.)
regards, tom lane
