Skip site navigation (1) Skip section navigation (2)

Re: [PERFORM] BUG #4919: CREATE USER command slows down system performance

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: David Wilson <david(dot)t(dot)wilson(at)gmail(dot)com>
Cc: Marko Kreen <markokr(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, toruvinn <toruvinn(at)lain(dot)pl>, pgsql-bugs(at)postgresql(dot)org, pgsql-performance(at)postgresql(dot)org
Subject: Re: [PERFORM] BUG #4919: CREATE USER command slows down system performance
Date: 2009-07-15 15:30:26
Message-ID: 23164.1247671826@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-bugspgsql-performance
David Wilson <david(dot)t(dot)wilson(at)gmail(dot)com> writes:
> On Wed, Jul 15, 2009 at 11:10 AM, Marko Kreen<markokr(at)gmail(dot)com> wrote:
>> From security standpoint, wasting more cycles on bad passwords is good,
>> as it decreases the rate bruteforce password scanning can happen.
>> 
>> And I cannot imagine a scenario where performance on invalid logins
>> can be relevant..

> DoS attacks. The longer it takes to reject an invalid login, the fewer
> invalid login attempts it takes to DoS the server.

Yeah, but even with the current setup, an attacker who can fire
connection request packets at your postmaster port is not going to have
any trouble DoS'ing the service.  We expend quite a lot of cycles before
getting to the password challenge already.

			regards, tom lane

In response to

pgsql-performance by date

Next:From: Marko KreenDate: 2009-07-15 15:31:25
Subject: Re: [PERFORM] BUG #4919: CREATE USER command slows down system performance
Previous:From: David WilsonDate: 2009-07-15 15:16:23
Subject: Re: [PERFORM] BUG #4919: CREATE USER command slows down system performance

pgsql-bugs by date

Next:From: Marko KreenDate: 2009-07-15 15:31:25
Subject: Re: [PERFORM] BUG #4919: CREATE USER command slows down system performance
Previous:From: Alan PinsteinDate: 2009-07-15 15:27:58
Subject: Re: BUG #4921: ltree @> ltree[] operator shouldn't fail if ltree[] is empty

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group