Re: How to cripple a postgres server

Stephen Robert Norris <srn(at)commsecure(dot)com(dot)au> writes:
> 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.

Good point. And certainly the async-notify code (which scans through
pg_listener) is a lot more expensive than is needed just to respond to
an SInval-queue-full condition; that looks to be a quick hack that was
inserted without thought to performance. But I don't think we quite
understand this issue yet. If your system can support 800 simultaneous
useful queries then it shouldn't have a problem with 800 simultaneous
scans of an empty pg_listener table.

I'll ask again: is your system sized to support 800 *simultaneous*
user queries? (One query per second on 800 connections is hardly
the same thing.)

regards, tom lane