Re: idle_in_transaction_timeout

From: Vik Fearing <vik(dot)fearing(at)dalibo(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Kevin Grittner <kgrittn(at)ymail(dot)com>, Abhijit Menon-Sen <ams(at)2ndquadrant(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-24 14:50:03
Message-ID: 53A9901B.1050005@dalibo.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 06/24/2014 04:04 PM, Robert Haas wrote:
>> If the local transaction is actually idle in transaction and the local
>> > server doesn't have a timeout, we're no worse off than before this patch.
>
> I think we are. First, the correct timeout is a matter of
> remote-server-policy, not local-server-policy. If the remote server
> wants to boot people with long-running idle transactions, it's
> entitled to do that, and postgres_fdw shouldn't assume that it's
> "special".

So how would the local transaction ever get its work done? What option
does it have to tell the remote server that it isn't actually idling, it
just doesn't need to use the remote connection for a while?

Once the remote times out, the local transaction is doomed (and won't
even know it until it tries to commit). If we don't allow the fdw to be
special, then the local transaction can't run at all. Ever.

The point of the patch is to allow the DBA to knock off broken clients,
but this isn't a broken client, it just looks like one.
--
Vik

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2014-06-24 15:05:49 Re: API change advice: Passing plan invalidation info from the rewriter into the planner?
Previous Message Alvaro Herrera 2014-06-24 14:47:22 Re: crash with assertions and WAL_DEBUG