Re: Request: pg_cancel_backend variant that handles 'idle in transaction' sessions

2015-11-04 15:50 GMT+01:00 Merlin Moncure <mmoncure(at)gmail(dot)com>:

> On Wed, Nov 4, 2015 at 8:42 AM, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)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
>