2015-11-04 15:50 GMT+01:00 Merlin Moncure <mmonc...@gmail.com>: > On Wed, Nov 4, 2015 at 8:42 AM, Pavel Stehule <pavel.steh...@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 >
