Re: [patch]socket_timeout in interfaces/libpq
От | David Steele |
---|---|
Тема | Re: [patch]socket_timeout in interfaces/libpq |
Дата | |
Msg-id | ca382d74-e3ae-6467-d2b2-7ef98fd8f996@pgmasters.net обсуждение исходный текст |
Ответ на | RE: [patch]socket_timeout in interfaces/libpq ("nagaura.ryohei@fujitsu.com" <nagaura.ryohei@fujitsu.com>) |
Ответы |
Re: [patch]socket_timeout in interfaces/libpq
|
Список | pgsql-hackers |
On 11/29/19 12:22 AM, nagaura.ryohei@fujitsu.com wrote: > >> From: Michael Paquier <michael@paquier.xyz> >> On Wed, Jun 26, 2019 at 11:56:28AM +0000, nagaura.ryohei@fujitsu.com wrote: >>> It seems that you did not think so at that time. >>> # Please refer to [1] >>> >>> I don't think all the reviewers are completely negative. >> >> I recall having a negative impression on the patch when first looking at it, and still >> have the same impression when looking at the last version. Just with a quick >> look, assuming that you can bypass all cleanup operations normally taken by >> pqDropConnection() through a hijacking of pqWait() is not fine as this routine >> explicitely assumes to *never* have a timeout for its wait. > > I couldn't understand what you meant. > Do you say that we shouldn't change pqWait() behavior? > Or should I modify my patch to use pqDropConnection()? This patch no longer applies: http://cfbot.cputube.org/patch_27_2175.log CF entry has been updated to Waiting on Author. More importantly it looks like there is still no consensus on this patch, which is an uncommitted part of a previous patch [1]. Unless somebody chimes in I'll mark this Returned with Feedback at the end of the CF. Regards, -- -David david@pgmasters.net [1] https://www.postgresql.org/message-id/raw/20190406065428.GA2145%40paquier.xyz
В списке pgsql-hackers по дате отправления: