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

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.

In response to

Responses

Browse pgsql-bugs by date

  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