Re: How to cripple a postgres server

Stephen Robert Norris <srn@commsecure.com.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