Merlin Moncure <> writes:
>> Yes, and that is what I meant.  I have two problems with
>> transaction_idle_timeout (as opposed to transaction_timeout):
>> A) It's more complex.  Unsophisticated administrators may not
>> understand or set it properly
>> B) There is no way to enforce an upper bound on transaction time with
>> that setting.  A pathological application could keep a transaction
>> open forever without running into any timeouts -- that's a dealbreaker
>> for me.
>> From my point of view the purpose of the setting should be to protect
>> you from any single actor from doing things that damage the database.
>> 'idle in transaction' happens to be one obvious way, but upper bound
>> on transaction time protects you in general way.

> Note, having both settings would work too.

I'd vote for just transaction_timeout.  The way our timeout manager
logic works, that should be more efficient, as the timeout would only
have to be established once at transaction start, not every time the
main command loop iterates.

                        regards, tom lane

Sent via pgsql-hackers mailing list (
To make changes to your subscription:

Reply via email to