Josh Berkus <j...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
