| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Josh Berkus <josh(at)agliodbs(dot)com> |
| Cc: | Vik Fearing <vik(dot)fearing(at)dalibo(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Kevin Grittner <kgrittn(at)ymail(dot)com>, Abhijit Menon-Sen <ams(at)2ndquadrant(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Andrew Dunstan <andrew(at)dunslane(dot)net> |
| Subject: | Re: idle_in_transaction_timeout |
| Date: | 2014-06-24 17:05:10 |
| Message-ID: | 20908.1403629510@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Josh Berkus <josh(at)agliodbs(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2014-06-24 17:09:08 | Re: Atomics hardware support table & supported architectures |
| Previous Message | Noah Misch | 2014-06-24 17:03:37 | Re: Atomics hardware support table & supported architectures |