Re: pg_listener entries deleted under heavy NOTIFY load only on Windows

Поиск
Список
Период
Сортировка
От Marshall, Steve
Тема Re: pg_listener entries deleted under heavy NOTIFY load only on Windows
Дата
Msg-id 8536F69C1FCC294B859D07B179F0694411D4BA6A@EXCHANGE.ad.wsicorp.com
обсуждение исходный текст
Ответ на Re: pg_listener entries deleted under heavy NOTIFY load only on Windows  (Magnus Hagander <magnus@hagander.net>)
Ответы Re: pg_listener entries deleted under heavy NOTIFY load only on Windows  (Magnus Hagander <magnus@hagander.net>)
Список pgsql-bugs
What's the timing of the errors? Is there a chance that we are sending
the kill signal before the signal handling thread has actually started
*and created the named pipe*?=20

We set up the signal handling stuff pretty early, but we do seem to let
the postmaster continue it's work before it's up...

Under heavy load, a signal will typically be dropped within the first
few minutes.  However, it can sometimes take a little while before the
problem happens.  Thousands of the same signal to the same process may
be properly handled before one is mishandled.  This is not consistant
with a problem with initial creation of the pipe.

Going back to your tests, did it ever require more than one retry?

Yes, but rarely. In a 90 hour stress test with code that allowed up to 5
calls to CallNamedPipe, I found 760 signals that required a retry.  Only
one required two retries.  That is why I set the number of retries to 2.
The behavior might be different if the sleep interval between retries
was changed.  I used a 20 ms sleep interval between retries in all my
tests, and in the patch I sent.

В списке pgsql-bugs по дате отправления:

Предыдущее
От: Magnus Hagander
Дата:
Сообщение: Re: pg_listener entries deleted under heavy NOTIFY load only on Windows
Следующее
От: raf
Дата:
Сообщение: Re: Set-returning functions only allowed if written in language 'sql'