Re: idle_in_transaction_timeout

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Josh Berkus <josh(at)agliodbs(dot)com>
Cc: Andres Freund <andres(at)2ndquadrant(dot)com>, Kevin Grittner <kgrittn(at)ymail(dot)com>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, 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>, Andrew Dunstan <andrew(at)dunslane(dot)net>
Subject: Re: idle_in_transaction_timeout
Date: 2014-06-24 16:53:08
Message-ID: CAFj8pRCOdb9yWVfjbzJPQV-XHCyD3mqVKiqisPa1nyk1-+VQUQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

2014-06-24 18:43 GMT+02:00 Josh Berkus <josh(at)agliodbs(dot)com>:

> On 06/23/2014 03:52 PM, Andres Freund wrote:
> > On 2014-06-23 13:19:47 -0700, Kevin Grittner wrote:
> >>>>> which already seems less clear (because the transaction belongs
> >>>>> to idle)
> >>
> >> I have no idea what that means.
> >
> > It's "idle_in_transaction"_session_timeout. Not
> > "idle_in"_transaction_session_timeout.
> >
> >>>>> and for another that distinction seems to be to subtle for users.
> >>
> >> The difference between an "idle in transaction session" and an
> >> "idle transaction" is too subtle for someone preparing to terminate
> >> one of those?
> >
> > Yes. To me that's an academic distinction. As a nonnative speaker it
> > looks pretty much random that one has an "in" in it and the other
> > doesn't. Maybe I'm just having a grammar fail, but there doesn't seem to
> > be much sense in it.
>
> As a native speaker, I find the distinction elusive as well. If someone
> was actually planning to commit transaction cancel, I'd object to it.
>
> And frankly, it doesn't make any sense to have two independent timeouts
> anyway. Only one of them would ever be invoked, whichever one came
> first. If you really want to plan for a feature I doubt anyone is going
> to write, the appropriate two GUCs are:
>
> idle_transaction_timeout: ## ms
> idle_transaction_timeout_action: cancel | terminate
>
> However, since I'm not convinced that anyone is ever going to write the
> "cancel" version, can we please just leave the 2nd GUC out for now?
>
> >>> A long idle in transaction state pretty much always indicates a
> >>> problematic interaction with postgres.
> >>
> >> True. Which makes me wonder whether we shouldn't default this to
> >> something non-zero -- even if it is 5 or 10 days.
>
> I'd go for even shorter: 48 hours. I'd suggest 24 hours, but that would
> trip up some users who just need really long pg_dumps.
>

long transactions should not be a problem - this should to break
transaction when it does >>nothing<< long time.

Regards

Pavel

>
> --
> Josh Berkus
> PostgreSQL Experts Inc.
> http://pgexperts.com
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Merlin Moncure 2014-06-24 16:57:53 Re: [BUGS] BUG #10728: json_to_recordset with nested json objects NULLs columns
Previous Message Vik Fearing 2014-06-24 16:52:34 Re: idle_in_transaction_timeout