RE: Transactions involving multiple postgres foreign servers, take 2
От | tsunakawa.takay@fujitsu.com |
---|---|
Тема | RE: Transactions involving multiple postgres foreign servers, take 2 |
Дата | |
Msg-id | TYAPR01MB29905E6C5C5A2ABD037EC60EFE070@TYAPR01MB2990.jpnprd01.prod.outlook.com обсуждение исходный текст |
Ответ на | Re: Transactions involving multiple postgres foreign servers, take 2 (Masahiko Sawada <masahiko.sawada@2ndquadrant.com>) |
Ответы |
Re: Transactions involving multiple postgres foreign servers, take 2
|
Список | 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 по дате отправления: