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.
you wrote "transaction_timeout: cancels transaction after X time, regardless of > state" - I understand if text is "cancels transaction after X time if state is "idle in tramsaction"
Pavel
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
