Skip site navigation (1) Skip section navigation (2)

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

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: (view raw, whole thread or download thread mbox)
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.


In response to

pgsql-bugs by date

Next:From: David NewallDate: 2009-02-16 00:14:36
Subject: Re: Lost search_path after transaction fails
Previous:From: Glen EdmondsDate: 2009-02-14 22:51:54
Subject: BUG #4655: Spelling mistake in windows installer

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group