Re: idle_in_transaction_timeout - Mailing list pgsql-hackers

From Josh Berkus
Subject Re: idle_in_transaction_timeout
Date
Msg-id 53A9AE20.7090901@agliodbs.com
Whole thread Raw
In response to Re: idle_in_transaction_timeout  (Josh Berkus <josh@agliodbs.com>)
Responses Re: idle_in_transaction_timeout  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On 06/24/2014 07:50 AM, Vik Fearing 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?
> 
> 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.

I'm unclear on how the FDW could be special.  From the point of the
remote server, how does it even know that it's receiving an FDW
connection and not some other kind of connection?

-- 
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com



pgsql-hackers by date:

Previous
From: Merlin Moncure
Date:
Subject: Re: [BUGS] BUG #10728: json_to_recordset with nested json objects NULLs columns
Next
From: Noah Misch
Date:
Subject: Re: Atomics hardware support table & supported architectures