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