On Sun, Nov 28, 2010 at 5:41 PM, Jeff Janes <jeff.ja...@gmail.com> wrote: > On Sun, Nov 28, 2010 at 5:38 AM, Robert Haas <robertmh...@gmail.com> wrote: >> On Sat, Nov 27, 2010 at 2:44 PM, Jeff Janes <jeff.ja...@gmail.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
