From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
Cc: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Magnus Hagander <magnus(at)hagander(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Request: pg_cancel_backend variant that handles 'idle in transaction' sessions |
Date: | 2015-11-04 17:11:36 |
Message-ID: | 6827.1446657096@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Merlin Moncure <mmoncure(at)gmail(dot)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.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2015-11-04 17:15:28 | Re: Request: pg_cancel_backend variant that handles 'idle in transaction' sessions |
Previous Message | Joe Conway | 2015-11-04 16:20:28 | Re: [patch] Proposal for \rotate in psql |