RE: Transactions involving multiple postgres foreign servers, take 2 - Mailing list pgsql-hackers

From tsunakawa.takay@fujitsu.com
Subject RE: Transactions involving multiple postgres foreign servers, take 2
Date
Msg-id TYAPR01MB29905E6C5C5A2ABD037EC60EFE070@TYAPR01MB2990.jpnprd01.prod.outlook.com
Whole thread Raw
In response to Re: Transactions involving multiple postgres foreign servers, take 2  (Masahiko Sawada <masahiko.sawada@2ndquadrant.com>)
Responses Re: Transactions involving multiple postgres foreign servers, take 2
List pgsql-hackers
From: Masahiko Sawada <masahiko.sawada@2ndquadrant.com>
> I was thinking to have a GUC timeout parameter like statement_timeout.
> The backend waits for the setting value when resolving foreign
> transactions.

Me too.


> But this idea seems different. FDW can set its timeout
> via a transaction timeout API, is that right?

I'm not perfectly sure about how the TM( application server works) , but probably no.  The TM has a configuration
parameterfor transaction timeout, and the TM calls XAResource.setTransactionTimeout() with that or smaller value for
theargument.
 


> But even if FDW can set
> the timeout using a transaction timeout API, the problem that client
> libraries for some DBMS don't support interruptible functions still
> remains. The user can set a short time to the timeout but it also
> leads to unnecessary timeouts. Thoughts?

Unfortunately, I'm afraid we can do nothing about it.  If the DBMS's client library doesn't support cancellation (e.g.
doesn'trespond to Ctrl+C or provide a function that cancel processing in pgorogss), then the Postgres user just finds
thathe can't cancel queries (just like we experienced with odbc_fdw.)
 


 Regards
Takayuki Tsunakawa


pgsql-hackers by date:

Previous
From: Masahiko Sawada
Date:
Subject: Re: Transactions involving multiple postgres foreign servers, take 2
Next
From: Julien Rouhaud
Date:
Subject: Re: Feature improvement: can we add queryId for pg_catalog.pg_stat_activity view?