2015-11-04 18:11 GMT+01:00 Tom Lane <t...@sss.pgh.pa.us>: > Merlin Moncure <mmonc...@gmail.com> 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. >
I cannot to say, so transaction_timeout is not useful, but it cannot be effective solution for some mentioned issues. With larger data you cannot to set transaction_timeout less than few hours. Regards Pavel > > regards, tom lane >
