Re: idle_in_transaction_timeout

From: Abhijit Menon-Sen <ams(at)2ndquadrant(dot)com>
To: Kevin Grittner <kgrittn(at)ymail(dot)com>
Cc: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Vik Fearing <vik(dot)fearing(at)dalibo(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: idle_in_transaction_timeout
Date: 2014-06-19 16:03:50
Message-ID: 20140619160350.GF31357@toroid.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

At 2014-06-19 08:42:01 -0700, kgrittn(at)ymail(dot)com wrote:
>
> I'm not sure whether using the same name as pgbouncer for the same
> functionality makes it less confusing or might lead to confusion
> about which layer is disconnecting the client.

I don't think the names of the respective configuration settings will
significantly affect that confusion either way.

(I can imagine people being confused if they're using pgbouncer without
the timeout in front of a server with the timeout. But since they would
have to have turned it on explicitly on the server, it can't all THAT
much of a surprise. Or at least not that hard to figure out.)

> As long as BEGIN causes a connection to show as "idle in transaction"
> I think the BEGIN should start the clock on this timeout, based on
> POLA.

Yes, agreed. I don't think it's worth doing anything more complicated.

> Also, it seems like most are ok with the FATAL approach (as in v1
> of this patch).

I don't have a strong opinion, but I think FATAL is the pragmatic
approach.

-- Abhijit

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Joe Conway 2014-06-19 16:08:56 Re: [bug fix] Memory leak in dblink
Previous Message Kevin Grittner 2014-06-19 15:57:18 Re: delta relations in AFTER triggers