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

Re: contrib: auth_delay module

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
Cc: Stephen Frost <sfrost(at)snowman(dot)net>, Jan Urbański <wulczer(at)wulczer(dot)org>, Itagaki Takahiro <itagaki(dot)takahiro(at)gmail(dot)com>, KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>, PostgreSQL-Hackers <pgsql-hackers(at)postgresql(dot)org>, KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>
Subject: Re: contrib: auth_delay module
Date: 2010-11-28 23:57:11
Message-ID: AANLkTikeKOc+m5G37hkD6S0WeyFj7GcYOodvvJcGR5NA@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Sun, Nov 28, 2010 at 5:41 PM, Jeff Janes <jeff(dot)janes(at)gmail(dot)com> wrote:
> On Sun, Nov 28, 2010 at 5:38 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> On Sat, Nov 27, 2010 at 2:44 PM, Jeff Janes <jeff(dot)janes(at)gmail(dot)com> wrote:
>
>>> 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.
>
> Right, I didn't think of using psql, I thought I'd have to wrangle my
> own socket code.
>
> I wrote up a perl script that spawns psql and immediately kills it.  I
> quickly start getting "psql: FATAL:  sorry, too many clients already"
> errors.  And that condition doesn't clear until the sleep expires on
> the earliest ones spawned.
>
> So it looks like the max_connections is charged until the auth_delay expires.

Yeah.  Avoiding that would be hard, and it's not clear that there's
any demand.  The demand for doing this much seems a bit marginal too,
but there were several people who seemed to think it worth committing,
so I did.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

pgsql-hackers by date

Next:From: Robert HaasDate: 2010-11-29 00:08:10
Subject: Re: profiling connection overhead
Previous:From: KaiGai KoheiDate: 2010-11-28 23:50:07
Subject: Re: [GENERAL] column-level update privs + lock table

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