Re: idle_in_transaction_timeout

On Tue, Jun 24, 2014 at 9:20 AM, Vik Fearing [via PostgreSQL] <
ml-node+s1045698n5808882h66(at)n5(dot)nabble(dot)com> wrote:

> On 06/22/2014 05:11 PM, Kevin Grittner wrote:
> > I found one substantive issue that had been missed in discussion,
> > though. The patch modifies the postgres_fdw extension to make it
> > automatically exempt from an attempt to set a limit like this on
> > the server to which it connects. I'm not sure that's a good idea.
> > Why should this type of connection be allowed to sit indefinitely
> > with an idle open transaction? I'm inclined to omit this part of
> > the patch
>
> My reasoning for doing it the way I did is that if a transaction touches
> a foreign table and then goes bumbling along with other things the
> transaction is active but the connection to the remote server remains
> idle in transaction. If it hits the timeout, when the local transaction
> goes to commit it errors out and you lose all your work.
>
> 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.
>

​Going off of this reading alone wouldn't we have to allow the client to
set the timeout on the fdw_server - to zero - to ensure reasonable
operation? If the client has a process that requires ​10 minutes to
complete, and the foreign server has a default 5 minute timeout, if the
client does not disable the timeout on the server wouldn't the foreign
server always cause the process to abort?

David J.

--
View this message in context: http://postgresql.1045698.n5.nabble.com/idle-in-transaction-timeout-tp5805859p5808883.html
Sent from the PostgreSQL - hackers mailing list archive at Nabble.com.