Re: How to cripple a postgres server

On Tue, 2002-05-28 at 13:21, Tom Lane wrote:
> Stephen Robert Norris <srn@commsecure.com.au> writes:
> > On Tue, 2002-05-28 at 12:44, Tom Lane wrote:
> >> Hmm, you mean if the 800 other connections are *not* idle, you can
> >> do VACUUMs with impunity?  If so, I'd agree we got a bug ...
>
> > Yes, that's what I'm saying.
>
> Fascinating.
>
> > I suspect the comment near the async_notify code explains the problem -
> > where it talks about idle backends having to be woken up to clear out
> > pending events...
>
> Well, we need to do that, but your report seems to suggest that that
> code path isn't getting the job done completely --- my first guess is
> that a new normal query has to arrive before a SIGUSR2'd backend is
> completely happy again.  Interesting.
>
> You didn't specify: what PG version are you running, and on what
> platform?
>
>             regards, tom lane

Sorry, forgot that.

PG 7.1 or 7.2 (both have the problem) on linux 2.2.x (x>=17) and 2.4.x
(4 <= x <= 18).

I've tried a variety of intel machines (and AMD machines) and managed to
reproduce the same problem.

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, 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...

    Stephen