From: | Magnus Hagander <magnus(at)hagander(dot)net> |
---|---|
To: | "Marshall, Steve" <smarshall(at)wsi(dot)com> |
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-15 13:59:05 |
Message-ID: | 49981FA9.8050407@hagander.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Marshall, Steve wrote:
> 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.
I have applied a modified version (no functional changes, just
stylistic) of this patch to head and backpatched to 8.2 which is as far
back as we support win32.
//Magnus
From | Date | Subject | |
---|---|---|---|
Next Message | David Newall | 2009-02-16 00:14:36 | Re: Lost search_path after transaction fails |
Previous Message | Glen Edmonds | 2009-02-14 22:51:54 | BUG #4655: Spelling mistake in windows installer |