Re: idle_in_transaction_timeout

On 2014-06-23 20:29:17 +0900, Fujii Masao wrote:
> On Mon, Jun 23, 2014 at 7:48 PM, Andres Freund <andres(at)2ndquadrant(dot)com> wrote:
> > On 2014-06-22 19:03:32 -0700, Kevin Grittner wrote:
> >> Andres Freund <andres(at)2ndquadrant(dot)com> wrote:
> >>
> >> > I think we'll want a version of this that just fails the
> >> > transaction once we have the infrastructure. So we should choose
> >> > a name that allows for a complimentary GUC.
> >>
> >> If we stick with the rule that what is to the left of _timeout is
> >> what is being cancelled, the a GUC to cancel a transaction which
> >> remains idle for too long could be called idle_transaction_timeout.
> >>
> >> Do you disagree with the general idea of following that pattern?
> >
> > I think that'd be rather confusing. For one it'd need to be
> > idle_in_transaction_timeout which already seems less clear (because the
> > transaction belongs to idle) and for another that distinction seems to
> > be to subtle for users.
> >
> > The reason I suggested
> > idle_in_transaction_termination/cancellation_timeout is that that maps
> > nicely to pg_terminate/cancel_backend() and is rather descriptive.
>
> Maybe we can remove IIT_termination_timeout when we've implemented
> IIT_cancellation_timeout. Right? I'm not sure if IIT_termination_timeout is
> still useful even at that case.

I think both can actually be sensible depending on the use case. It's
also not nice to remove a feature without need when people started to
rely on it.
For a web app termination is probably more sensible. For interactive
clients cancellation.

> *If* it's not useful, I think we don't need to
> have those two parameters and can just define one parameter IIT_timeout.
> That's quite simple and it's similar to the current style of statement_timeout
> and lock_timeout (IOW, we don't have something like
> statement_termination_timeout and lock_termination_timeout).

I don't think those really are comparable. A long idle in transaction
state pretty much always indicates a problematic interaction with
postgres.

Greetings,

Andres Freund

--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services