Re: idle_in_transaction_timeout - Mailing list pgsql-hackers

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

One way you could do it is to use a user id that's only for FDW
connections, and do an ALTER ROLE on that id to set the appropriate
timeout.

Personally I'm violently against having postgres_fdw mess with this
setting; for one thing, the proposed coding would prevent DBAs from
controlling the timeout as they see fit, because it would override
any ALTER ROLE or other remote-side setting.  It doesn't satisfy the
POLA either.  postgres_fdw does not for example override
statement_timeout; why should it override this timeout?
        regards, tom lane



pgsql-hackers by date:

Previous
From: Noah Misch
Date:
Subject: Re: Atomics hardware support table & supported architectures
Next
From: Andres Freund
Date:
Subject: Re: Atomics hardware support table & supported architectures