On Mon, Jun 23, 2014 at 7:48 PM, Andres Freund <and...@2ndquadrant.com> wrote: > On 2014-06-22 19:03:32 -0700, Kevin Grittner wrote: >> Andres Freund <and...@2ndquadrant.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. *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). Regards, -- Fujii Masao -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
