On Wed, Nov 4, 2015 at 8:42 AM, Pavel Stehule <pavel.stehule@gmail.com> wrote:
>> > Okay, I think one more point to consider is that it would be preferable
>> > to
>> > have such an option for backend sessions and not for other processes
>> > like WalSender.
>>
>> All right...I see the usage.. I withdraw my objection to 'session'
>> prefix then now that I understand the case. So, do you agree that:
>>
>> *) session_idle_timeout: dumps the backend after X time in 'idle' state
>> and
>> *) transaction_timeout: cancels transaction after X time, regardless of
>> state
>>
>> sounds good?
>
>
> Not too much
>
> *) transaction_timeout: cancels transaction after X time, regardless of
> state
>
> This is next level of statement_timeout. I can't to image sense. What is a
> issue solved by this property?
That's the entire point of the thread (or so I thought): cancel
transactions 'idle in transaction'. This is entirely different than
killing idle sessions. BTW, I would never configure
session_idle_timeout, because I have no idea what that would do to
benign cases where connection poolers have grabbed a few extra
connections during a load spike. It's pretty common not to have
those applications have coded connection retry properly and it would
cause issues.
The problem at hand is idle *transactions*, not sessions, and a
configuration setting that deals with transaction time. I do not
understand the objection to setting an upper bound on transaction
time. I'm ok with cancelling or dumping the session with a slight
preference on cancel.
merlin
