Re: idle_in_transaction_timeout

From: Andres Freund <andres(at)2ndquadrant(dot)com>
To: Kevin Grittner <kgrittn(at)ymail(dot)com>
Cc: Vik Fearing <vik(dot)fearing(at)dalibo(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Josh Berkus <josh(at)agliodbs(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>
Subject: Re: idle_in_transaction_timeout
Date: 2014-06-23 10:48:07
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

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.


Andres Freund

Andres Freund
PostgreSQL Development, 24x7 Support, Training & Services

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Abhijit Menon-Sen 2014-06-23 10:51:53 Re: pgaudit - an auditing extension for PostgreSQL
Previous Message Fujii Masao 2014-06-23 10:15:39 Re: pgaudit - an auditing extension for PostgreSQL