sorry, too many clients already

[PatrickG]

I am getting the error "sorry, too many clients already" when running in release mode, but not debug mode.

I don't believe I should be getting this error at all because I have explicitly limited the connection pool size (50) and my postgresql.conf specifies max_connections to be 110.

Other than pdAdmin III, using 3 connections there are not any other connections to the database.

I am using the following connection string:
Host=127.0.0.1;Port=5432;Database=my_database;Unicode=True;Integrated Security=True;Max Pool Size=50;Pooling=True;


When I query pg_stat_activity, the current connections does get up to 110, then my application errors out with the previously stated error. All of the connections are idle, and every PgSqlConnection I call is in a using. So I am at a loss for what I could be doing wrong here.

Any suggestions?

Thanks,

Patrick

[PatrickG]

It looks like the problem only occurs when using integrated security, so there must be some sort of bug in the SSPI implementation...


Patrick

[Shalex]

I am getting the error "sorry, too many clients already" when running in release mode, but not debug mode.

Do you mean the Project > Properties > Build > Configuration setting of your project in Visual Studio (release/debug)? If yes, could you please try to localize the issue? Which exact setting of your release mode causes the problem?

[PatrickG]

I thought it was a debug/release problem initially, but it turned out to just be a problem when using SSPI / integrated security in my connection string. Connections in the pool are not being re-used. Each and every query executed creates a new connection in the pool until no more can be created, then the "sorry, too many clients already" exception is thrown.

Hope that helps, it is pretty easy to duplicate.

[cjbiggs]

PatrickG is correct. I am having the same problem. It is very easy to reproduce. I am using SSPI/GSS integrated security in my connection string and it is creating a new connection each time.

Thanks,

Charlie J.

[cjbiggs]

I am able to close the connection by overriding the dispose method for my EF Context. But I dont know if this is the best and safe way to do it.

protected override void Dispose(bool disposing)
{
Devart.Data.PostgreSql.PgSqlConnection.ClearAllPools();
//Devart.Data.PostgreSql.PgSqlConnection.ClearPool((PgSqlConnection)((EntityConnection)this.Connection).StoreConnection);

base.Dispose(disposing);
}

Thanks,

Charlie J.

[Shalex]

We are investigating the issue with SSPI/GSS connection pooling.

[Shalex]

The bug with connection pooling when using SSPI/GSS authentication is fixed. We will post here when the corresponding public build of dotConnect for PostgreSQL is available for download.

PatrickG, please send your e-mail, registration and company names, which you have used during registration of our product, to me (alexsh at devart*com). We will send an internal build with the fix to you.

[Shalex]

New build of dotConnect for PostgreSQL 5.50.237 is available for download now!
It can be downloaded from http://www.devart.com/dotconnect/postgr ... nload.html (trial version) or from Registered Users' Area (for users with valid subscription only).
For more information, please refer to http://www.devart.com/forums/viewtopic.php?t=22383 .