Francisco Figueiredo Jr Activities

Sometimes, Npgsql users receive errors when working with connection pooling. The problem appears when they try to open a new connection and receive the following message:   "Timeout while getting a connection from pool." This is caused when an attempt is made to get a connection from a pool which  has all its connections used. Most of the time this problem is a difficult one to track because it generally happens when the system is in production and not in the development phase. Of course. :) Some time ago, I received a report from Miłosz Kubański about such a problem. I told him I would work in a way to get more information so we could check what was happening. In order to help us find the problem, I added a little  "hack" to  Npgsql: Whenever an error while getting a connection from the pool occurs, Npgsql would log a stacktrace of the allocation of all the connections which were in the pool. Theoretically, those connections which were allo...

You may already know that VS.Net design time support has started a long time ago  and didn't have too much support since then.  Now that Npgsql release 2.0.12  is out, I want to put more attention to finish a version which adds design time support. I noticed that this is the biggest missing feature in Npgsql and I want to fix that. Npgsql users deserve to be able to use VS.Net design time support to help them create better apps which access Postgresql databases. Although I can't give any concrete timeframe of when it will be available, I want you to know that I'm focused on this feature and it is not stalled. I hope to be able to give you more information soon. Stay tuned.

Hi, all! Today I committed a change to Npgsql which will improve connection pool performance. This change was motivated by Andrew's bug report where he noticed that a lot of threads were waiting to get a new connection from pool. In order to keep consistence of the pool, Npgsql has to lock access to it. Andrew's problem appeared in a busy server where a lot of threads were trying to get a new connection from the pool. They had to wait in line. And obviously this isn't good. The current implementation of Npgsql creates a big lock surrounding all the code needed to work with the pool and more! As Andrew noticed in his bug report, I/O operations were being done inside this lock which was contributing to more delays to get a connection from the pool. So, to fix that, I rewrote connection pool logic to remove this big lock and break it down to smaller ones only when really needed. All the I/O operations were left out of the locks , this way, other threads...