RE: Transactions involving multiple postgres foreign servers, take 2
От | tsunakawa.takay@fujitsu.com |
---|---|
Тема | RE: Transactions involving multiple postgres foreign servers, take 2 |
Дата | |
Msg-id | TYAPR01MB299020D964525FE4AF341058FE1F0@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> > It seems to respond to a statement-cancel signal immediately while > waiting for a coming byte. However, seems to wait forever while > waiting a space in send-buffer. (Is that mean the session will be > stuck if it sends a large chunk of bytes while the network is down?) What part makes you worried about that? libpq's send processing? I've just examined pgfdw_cancel_query(), too. As below, it uses a hidden 30 second timeout. After all, postgres_fdw alsorelies on timeout already. /* * If it takes too long to cancel the query and discard the result, assume * the connection is dead. */ endtime = TimestampTzPlusMilliseconds(GetCurrentTimestamp(), 30000); > After receiving a signal, it closes the problem connection. So the > local session is usable after that but the fiailed remote sessions are > closed and created another one at the next use. I couldn't see that the problematic connection is closed when the cancellation fails... Am I looking at a wrong place? /* * If connection is already unsalvageable, don't touch it * further. */ if (entry->changing_xact_state) break; Regards Takayuki Tsunakawa
В списке pgsql-hackers по дате отправления: