On Sat, Nov 27, 2010 at 2:44 PM, Jeff Janes <jeff.ja...@gmail.com> wrote: > On Thu, Nov 4, 2010 at 6:35 AM, Stephen Frost <sfr...@snowman.net> wrote: >> * Jan Urbański (wulc...@wulczer.org) wrote: >>> On 04/11/10 14:09, Robert Haas wrote: >>> > Hmm, I wonder how useful this is given that restriction. >>> >>> As KaiGai mentined, it's more to make bruteforcing difficult (read: tmie >>> consuming), right? >> >> Which it would still do, since the attacker would be bumping up against >> max_connections. max_connections would be a DOS point, but that's no >> different from today. > > I haven' t thought of a way to test this, so I guess I'll just ask. > If the attacking client just waits a few milliseconds for a response > and then drops the socket, opening a new one, will the server-side > walking-dead process continue to be charged against max_connections > until it's sleep expires?
I'm not sure, either. I suspect the answer is yes. I guess you could test this by writing a loop like this: while true; do psql <connection parameters that will fail authentication>; done ...and then hitting ^C every few seconds during execution. After doing that for a bit, run select * from pg_stat_activity or ps auxww | grep postgres in another window. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
