On Tue, 2002-05-28 at 13:42, Tom Lane wrote:
> Stephen Robert Norris <srn@commsecure.com.au> writes:
> > To clarify my comments, I suspect the problem is that all 800 of the
> > backends get the SIGUSR2 at the same time, and all wake up,
>
> That would indeed happen ...
>
> > causing the
> > kernel scheduler to go mad trying to decide which one to schedule... If
> > the connections aren't idle, the queue never fills up enough to require
> > the signals...
>
> ... but it doesn't follow that this is causing your problem. All 800
> are going to get woken up at the same time anyway (or as close to the
> same time as the postmaster can issue the signals, that is). Why does
> it make a difference whether they have or soon will process a normal
> query? If you are able to prevent the problem by issuing "select 1"
> once per second on each connection, then for sure it's not a case of
> whether they are busy at receipt of the signal or not. Most of 'em
> will not be busy at any given instant, with a load as trivial as that.
>
> Do you use LISTEN/NOTIFY at all? When was your pg_listener table
> last vacuumed?
>
> regards, tom lane
My reading of the code was that the signals didn't get delivered unless
the queue got too full, and that entries on the queue are created by the
vacuum (and other stuff) and processed when a backend does something,
thus the queue never gets too full.
My test program just cycles through each connection doing the select 1
on each in series.
No LISTEN/NOTIFY at all. I've been creating entirely new db setups to
test it (with initdb).
Stephen