From: | "Marshall, Steve" <smarshall(at)wsi(dot)com> |
---|---|
To: | "Magnus Hagander" <magnus(at)hagander(dot)net> |
Cc: | <pgsql-bugs(at)postgresql(dot)org>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Subject: | Re: pg_listener entries deleted under heavy NOTIFY load only on Windows |
Date: | 2009-02-10 14:42:54 |
Message-ID: | 8536F69C1FCC294B859D07B179F0694411D4BA6A@EXCHANGE.ad.wsicorp.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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*?
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.
From | Date | Subject | |
---|---|---|---|
Next Message | raf | 2009-02-10 23:48:16 | Re: Set-returning functions only allowed if written in language 'sql' |
Previous Message | Magnus Hagander | 2009-02-10 14:29:23 | Re: pg_listener entries deleted under heavy NOTIFY load only on Windows |