Skip to main content

Npgsql Connection Pool Explained

Hi all!

From time to time, we receive some questions regarding connection pool in Npgsql and I think I should post some info about its current design.

Npgsql connection pool implements the common pattern of having some connections open beforehand so when one is needed, it will be readily available for using.

How it works

When a application opens a connection, Npgsql tries to find a pool of connections based on the connection string. If a pool doesn't exist, it is created with a number of connections specified in the MinPoolSize connectionstring parameter. After that, a connection is retrieved from this pool.

The min and max number of connections created in each pool is controlled by connection string parameters called MinPoolSize and MaxPoolSize respectively. This way, users can fine tune the pool behavior to match their scalability needs.

Npgsql controls the lifetime of unused connections in the pool, trying to get connections number near the minimum value set by user. This is done by closing unused connections which are open far long than NpgsqlConnection.ConnectionLifeTime. This control is helpful in a scenario where application uses a lot of connections in a peak situation and later goes back to normal connection usage. Those "extra" connections will stay open but won't be used anytime soon, so instead of laying there consuming server resources, Npgsql simply closes them when their lifetime is reached.

Applications also can clear a pool or all pools by using NpgsqlConnection.ClearPool() and NpgsqlConnection.ClearAllPools() static methods.


EOF Error Message

There is one error message which appears in server log with applications which use Npgsql with pooled connections. This is the error message:


LOG: unexpected EOF on client connection

This is generally caused when the application is terminated and there are connections in the pool. The Tcp connection is closed by the .Net framework without Npgsql sending the Terminate message. Sending the Terminate message to all open connections would be the best thing to do, but Npgsql, by itself, isn't be able to know when the application is being terminated and so the log is generated. According to docs, this disconnection will make the backend clean up and terminate the connection ok. So, the only drawback of this situation is this message log.

In order to get more information about Npgsql connection pooling, you may check the NpgsqlConnectorPool.cs file.

I hope this information helps developers to understand better how connection pool works with Npgsql.

If you have any other questions, please drop by Npgsql forums.

Comments

Sergio said…
This comment has been removed by the author.

Popular posts from this blog

Npgsql Tips: Using " in (...)" queries with parameters list and "any" operator

Hi, all! We have received some users questions about how to send a list of values to be used in queries using the "in" operator. Something like: select foo, bar from table where foo in (blah1, blah2, blah3); Npgsql supports array-like parameter values and the first idea to have this working would try to use it directly: NpgsqlCommand command = new NpgsqlCommand("select * from tablee where field_serial in (:parameterlist)", conn); ArrayList l = new ArrayList(); l.Add(5); l.Add(6); command.Parameters.Add(new NpgsqlParameter("parameterlist", NpgsqlDbType.Array | NpgsqlDbType.Integer)); command.Parameters[0].Value = l.ToArray(); NpgsqlDataReader dr = command.ExecuteReader(); but unfortunately this won't work as expected. Npgsql will send a query like this: select * from tablee where field_serial in ((array[5,6])::int4[]) And Postgresql will complain with the followin...

Using Entity Framework 6 with Npgsql 2.1.0

UPDATE (2014-05-19): Marek Beneš noticed a problem in the default connection factory config. It is fixed now. Thanks, Marek! UPDATE (2014-02-20): I created a new post explaining how to get Npgsql 2.1.0. Although this post is about EF 6, I'd like to talk about our current situation to support both EF 6 and EF4.x which explain why there are some subtle changes between EF 4.x and EF 6.x App.config settings.  Support for EF versions 4.x and 6.x Sometime after we started to work on Npgsql 2.1.0, we started to add code to support EF6 and decided to reorganize our Entity Framework support code. Shay created a pull request to organize this change and isolate the EF code out of core Npgsql code. The result was the creation of two separated assemblies: Npgsql.EntityFramework.dll for EF6 and above; Npgsql.EntityFrameworkLegacy.dll for EF4.x. Only when using Npgsql with EF6 you will need to reference Npgsql.EntityFramework.dll assembly. This is needed because the EF ...

Npgsql Design time support preview available for download!

UPDATE2 : For some reason, Blogger lost the original post. I had to republish it. UPDATE : Jerónimo told me that you  must  use the Npgsql version which is inside the zip file in order to make it work. After so much time (more than I wanted it to take) Npgsql finally has a initial design time support for Visual Studio! This work was done by Jerónimo Milea. Jerónimo let me know he was working on DDEX support on this thread  after I said I was working on DDEX support for Npgsql. He sent me his working copy and I started to play with it. Note that as a preview version many things may not work ok and we wanted you to provide us feedback so we can fix any bugs. You can download the project file from our downloads page . Design time support is provided as a zip file containing support code as well as a copy of Npgsql project file. So, everything you need to start working with design time support is already packaged for you. When you unzip the file, you will have ...