Re: Why is src/test/modules/committs/t/002_standby.pl flaky?
От | Thomas Munro |
---|---|
Тема | Re: Why is src/test/modules/committs/t/002_standby.pl flaky? |
Дата | |
Msg-id | CA+hUKGKwiqnkmuj6tJ6E+wBDDDhB3d6_Lzmm3O=ZhRb9P8ETAA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Why is src/test/modules/committs/t/002_standby.pl flaky? (Alexander Lakhin <exclusion@gmail.com>) |
Ответы |
Re: Why is src/test/modules/committs/t/002_standby.pl flaky?
|
Список | pgsql-hackers |
On Mon, Jan 10, 2022 at 12:00 AM Alexander Lakhin <exclusion@gmail.com> wrote: > Going down through the call chain, I see that at the end of it > WaitForMultipleObjects() hangs while waiting for the primary connection > socket event. So it looks like the socket, that is closed by the > primary, can get into a state unsuitable for WaitForMultipleObjects(). I wonder if FD_CLOSE is edge-triggered, and it's already told us once. I think that's what these Python Twisted guys are saying: https://stackoverflow.com/questions/7598936/how-can-a-disconnected-tcp-socket-be-reliably-detected-using-msgwaitformultipleo > I tried to check the socket state with the WSAPoll() function and > discovered that it returns POLLHUP for the "problematic" socket. Good discovery. I guess if the above theory is right, there's a memory somewhere that makes this level-triggered as expected by users of poll().
В списке pgsql-hackers по дате отправления: