On Tue, Jun 24, 2014 at 10:50 AM, Vik Fearing <vik.fearing@dalibo.com> wrote:
> 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?
It *is* idling. You're going to get bloat, and lock contention, and
so on, just as you would for any other idle session.
I mean, you could make this assumption about any session: I'm not done
with the transaction yet, e.g. I'm waiting for user input before
deciding what to do next. That doesn't mean that the DBA doesn't want
to kill it.
> 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.
If it walks like a duck, and quacks like a duck, it's a duck.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company