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.
The Enterprise PostgreSQL Company
In response to
pgsql-hackers by date
|Next:||From: Robert Haas||Date: 2010-11-29 00:08:10|
|Subject: Re: profiling connection overhead|
|Previous:||From: KaiGai Kohei||Date: 2010-11-28 23:50:07|
|Subject: Re: [GENERAL] column-level update privs + lock table|