On Sat, Nov 27, 2010 at 2:44 PM, Jeff Janes <jeff.janes@gmail.com> wrote:
> On Thu, Nov 4, 2010 at 6:35 AM, Stephen Frost <sfrost@snowman.net> wrote:
>> * Jan Urbański (wulczer@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
