RE: Transactions involving multiple postgres foreign servers, take 2
От | tsunakawa.takay@fujitsu.com |
---|---|
Тема | RE: Transactions involving multiple postgres foreign servers, take 2 |
Дата | |
Msg-id | TYAPR01MB2990C58834F7A1657BAB51D9FE1F0@TYAPR01MB2990.jpnprd01.prod.outlook.com обсуждение исходный текст |
Ответ на | Re: Transactions involving multiple postgres foreign servers, take 2 (Kyotaro Horiguchi <horikyota.ntt@gmail.com>) |
Ответы |
Re: Transactions involving multiple postgres foreign servers, take 2
|
Список | pgsql-hackers |
From: Kyotaro Horiguchi <horikyota.ntt@gmail.com> > At Tue, 20 Oct 2020 15:53:29 +0900, Masahiko Sawada > <masahiko.sawada@2ndquadrant.com> wrote in > > I think it doesn't matter whether in FDW framework or not. The user > > normally doesn't care which backend processes connecting to foreign > > servers. They will attempt to cancel the query like always if they > > realized that a backend gets stuck. There are surely plenty of users > > who use query cancellation. > > The most serious impact from inability of canceling a query on a > certain session is that server-restart is required to end such a > session. OK, as I may be repeating, I didn't deny the need for cancellation. Let''s organize the argument. * FDW in general My understanding is that the FDW feature does not stipulate anything about cancellation. In fact, odbc_fdw was uncancelable. What do we do about this? * postgres_fdw Fortunately, it is (should be?) cancelable whatever method we choose for 2PC. So no problem. But is it really cancellable now? What if the libpq call is waiting for response when the foreign server or network is down? "Inability to cancel requires database server restart" feels a bit exaggerating, as libpq has tcp_keepalive* and tcp_user_timeoutconnection parameters, and even without setting them, TCP timeout works. Regards Takayuki Tsunakawa
В списке pgsql-hackers по дате отправления: