Re: Request: pg_cancel_backend variant that handles 'idle in transaction' sessions - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Request: pg_cancel_backend variant that handles 'idle in transaction' sessions
Date
Msg-id 6827.1446657096@sss.pgh.pa.us
Whole thread Raw
In response to Re: Request: pg_cancel_backend variant that handles 'idle in transaction' sessions  (Merlin Moncure <mmoncure@gmail.com>)
Responses Re: Request: pg_cancel_backend variant that handles 'idle in transaction' sessions  (Pavel Stehule <pavel.stehule@gmail.com>)
List pgsql-hackers
Merlin Moncure <mmoncure@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.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Joe Conway
Date:
Subject: Re: [patch] Proposal for \rotate in psql
Next
From: Pavel Stehule
Date:
Subject: Re: Request: pg_cancel_backend variant that handles 'idle in transaction' sessions