Description of problem:

mod_auth_pgsql does not release database connections each time a
browser hits a page protected by it.  The result is an eventual
consumption of concurrently open database connections.

Version-Release number of selected component (if applicable):

mod_auth_pgsql-2.0.1-3.ent

How reproducible:

Always reproducable and resulting in an http DoS of web directories
protected by mod_auth_pgsql.

Steps to Reproduce:
1. password protect a directory via mod_auth_pgsql
2. authenticate a browser into the directory
3. reload the page lots of times
4. even with the database backend configured to handle many
connections (say, 128 or more), mod_auth_pgsql keeps opening new
connections until it maxes out at 64 similtanious connections. 

Actual results:

Many, many idle processes representing unclosed database connections
are created, e.g:

postgres  9397  0.0  0.3 12360 3644 pts/1    S    16:32   0:00
postgres: postgres hpgrants 127.0.0.1 idle

Apache begins to log messages like this:
[Fri Feb 13 16:58:40 2004] [error] [client 206.228.191.7]
mod_auth_pgsql database connection error reset failed FATAL:  Sorry,
too many clients already!

Browsers attempting to access mod_auth_psql protected pages get
"Internal Server Error" from Apache.

The overall result is that mod_auth_pgsql on RHE3 causes a delayed
DoS.  RHE2.1 does not have this problem.


Expected results:

Obviously, the server should continue to serve protected pages after
the first 64 hits.


Additional info:

Reading in the mod_auth_pgsql source/docs in the version used in RHE3,
an experimental method reusing open database connections was
implemented but had some problems.  It's possible (likely?) that the
source snapshot in RHE3 not only attempts to use this experimental
optimization, but is using a broken version of it.