Friday, November 05, 2010

Npgsql 2.0.11 released!

As I've said in my last post,  Npgsql 2.0.11 is finally here!

This release fixes the problem with bytea handling with Postgresql 9.0. This patch should have been applied a long time ago. My fault for not being there yet.

Also on this release, Josh Cooley fixed some other bugs related to EF.

Checkout the release notes here for more info and download it from here.

Npgsql bytea handling fix is coming...

Hi all!

I'm aware of this problem and it is already fixed. We will be doing a new release on the next few days. For while, the current workaround is to fallback to previous handling style by changing postgresql.conf file. More info can be found here.

Sorry for the problems this may have caused.

Going Flash-Free too.

UPDATE2: here is what I decided to do. I reenabled flash plugin on my google chrome. Now, everytime I use flash and have finished, I simply fire up activity monitor and kills chrome's flash handling process. I noticed it keeps using cpu even after I closed the page which used flash :) I think this way I can save on battery and heating. Let's see how far I can go with this setup.

UPDATE: well, it seemed I could couldn't go too far. There were a lot of videos I couldn't load anymore. Back to flash! :)

After seeing this post from John Gruber, I decided to remove flash from my macbook and disable it from Chrome. Let's  see what happens. I notice since a long time ago that Flash eats up a lot of cpu power. I think it only works ok on MS Windows. I hope Adobe can fix that.

I also opted in for youtube html5 version. So youtube videos are seeing in webm or h264. The problem is that those videos seem to eat up more cpu power than flash! :(

Another big missing thing is gtalk video in the browser. It seems to require Flash. Google, would you mind give us another alternative, please?

Well, that's it. Let's see what I get...

Sunday, September 19, 2010

Trip to Canada

Hi all!

Today I'm going to Canada. I took sometime out of my job and decided to visit Rocky Mountains. I'll also take a cruise to Alaska. They say it is an awesome experience!

This means I'll won't be able to work on Npgsql for while. I'll be back on 13th October.

I'll post photos later.

Monday, August 23, 2010

Npgsql receives donation of an MSDN subscription!!

Hi all!

It all started when Josh Cooley told me about this post:

I sent a mail talking about Npgsql and how a VS.Net would help us to add design time support and today I received a very nice mail saying that Npgsql was choosen to receive an MSDN subscription!

I'd like to thank the people who contributed to make this possible: Codebetter Crew: Ben Hall, Ward Bell, James Kovacs. Devlicious Crew: Hadi Hariri, Christopher Bennage, Tim Barcz, Rob ReynoldsLostechies Crew: Eric Hexter, Jimmy Bogard, Keith Dahlby and Josh Cooley for heads up!

Thank you very much! Your support to OSS projects is awesome!

And stay tuned for better support of Npgsql inside VS.Net :)

Tuesday, August 17, 2010

New Android Blog

Hi all!

I've been playing with Android for quite some time now and so I decided to create a blog where I'll talk about my experience with the platform and the projects I'm developing for it.

I invite you all who are interested in the platform to have a look at it.

This blog will continue to be about Npgsql, Mono and other relevant things. I decided to create another blog so I could concentrate posts about Android there.

Feedback, as always, is very welcome.

Saturday, August 14, 2010

Npgsql 2.0.10 and NpgsqlParameter.Value

Hi all!

As you may already know, Npgsql 2.0.10 is out. Besides the usual batch of bug fixes and enhancements, this release has a new feature which needs more attention as it may give you backward compatibility problems.

What happened?

With this release, we decided to implement a property in NpgsqlParameter which returns provider specific objects, just like SQLClient does.

NpgsqlParameter now features a property called NpgsqlValue. As you may guess, when you use it, you will receive a value whose type is Npgsql specific.

Why this change?

In the past, we had a lot of problems dealing how we would handle values which are specific to Npgsql, like NpgsqlTimestamp from others which are represented in CLR, like DateTime. This situation led to cast exceptions bugs. This was the main motivation for this.

Also, we think that by implementing this we would be giving our users a much consistent way of getting values in CLR type and in Npgsql-specific type. Another benefit is that now Npgsql can behave better inside DataSet and DataRow objects as they use Value property and expect CLR types being returned.

What is the problem and what can I do about it?

The problem lies in the fact that now, NpgsqlParameter.Value returns only CLR types. So, if your code was expecting to receive Npgsql specific types you may need to change your code to either use CLR type or change the call to NpgsqlValue property.

I think the first option is a good one as it will make your code more portable between other providers. If you are using only Npgsql, second option is a better choice as it will allow you to use directly Npgsql specific types.

We would like to hear from you how this modification is working for you.
Please, post your questions and suggestions in our user forums.

Thanks in advance.

Sunday, July 11, 2010

Did I say already that I'm loving MonoDevelop?

After seeing Miguel's post about the Navigation features of Monodevelop, I updated my Monodevelop version to 2.4 and I couldn't agree more with Miguel's opinion: Navigate To is the best feature of Monodevelop. It is awesome!!

You remember the type you want to work with, press Command-. (I'm using OS X), type part of its name (Monodvelop guys did an wonderful job about how little you have to type to find it) and voilà, your type is open and ready to edit!

See more features of Monodevelop here.

Thursday, April 29, 2010

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.

Sunday, April 04, 2010

Function call performance optimizations

On my last post about that subject, I wrote about some optimizations I did to get better performance when calling functions with Npgsql.

While that optimizations were very nice, they had a drawback: you had to reuse your NpgsqlCommand object. You had to reuse it because the optimizations were based on cached data and if you created a new NpgsqlCommand object the data would need to be cached again.

In the general case, where you would create many NpgsqlCommand objects and call functions with them, you would not benefit from those optimizations.

In order to fix that, Noah Misch created a patch which remove 2 of the 3 internal calls which were giving performance problems.

The only case left is for functions which have return type of 'record'. We are working to get this case also covered.

I'm going to show here how much performance improvement you get with this patch with a simple call to a function which returns an integer. This function is on Npgsql unit test suite, but I reproduce it here just for completeness:

create function funcA() returns int as '
select 0;

' language 'sql';

I'm going to compare the latest stable release version Npgsql 2.0.8 with our latest cvs version with Noah's patch.

In a loop of 100 iteractions, this is what we get with Npgsql 2.0.8 and Npgsql cvs:

Npgsql 2.0.8:

time mono teste.exe

real 0m0.537s
user 0m0.457s
sys 0m0.028s

Npgsql cvs:

time mono teste.exe

real 0m0.467s
user 0m0.420s
sys 0m0.026s

It is 13% faster!

If we raise the number of interactions to 1000 we get:

Npgsql 2.0.8:

time mono teste.exe

real 0m1.237s
user 0m0.698s
sys 0m0.089s

Npgsql cvs:

time mono teste.exe

real 0m0.655s
user 0m0.492s
sys 0m0.054s

Which gives 47% improvement!

So, when next Npgsql release is out, we can see a modest to good performance improvement in function calling scenarios using Npgsql.

If you want to try it out today, please grab the latest cvs code and let us know what do you get.

Please, leave your comments and feedback. Also, participate on our Forums so you can share your experience.

Friday, April 02, 2010

Using SSL Client Certificates with Npgsql

Hi all!

Recently, Jarrod Kinsley asked on our Forums how to establish an SSL connection. As Laurenz Albe pointed out, normally you just need to change your connection string to put "SSL=True;Sslmode=Require;" in your connection string and "ssl=on" in postgresql.conf and you are ready to go.

The problem was that this works in the general case where you don't have to deal with client certificates and other stuff. Npgsql has a lot of callbacks to help you to validate and talk to the server.

The last callback added to the chain by Frank Bollack was to provide a way to pass client certificates to server.

Later on the thread, Jennifer Marienfeld was also trying to connect and was stuck in the client certificate part. Jennifer eventually got success to establish connection to the server and I decided to create this post to show the code so others can benefit from this.

Here is Jennifer's code so you all can use as a template:

using System;
using System.IO;
using System.Security.Cryptography;
using System.Security.Cryptography.X509Certificates;

using Npgsql;
using Mono.Security.Protocol.Tls;
using Mono.Security.Authenticode;

namespace my
class Program
public static void Main(string[] args)
string conStr =
";" +
"User Id=xxx;" +
"Password=xxx;" +
"Protocol=3;" +
"Database=xxx;" +
"SSL=True;" +

NpgsqlConnection conn = new NpgsqlConnection(conStr);

conn.ProvideClientCertificatesCallback += new ProvideClientCertificatesCallback(

conn.CertificateSelectionCallback +=
new CertificateSelectionCallback(

conn.CertificateValidationCallback +=
new CertificateValidationCallback(

conn.PrivateKeySelectionCallback +=
new PrivateKeySelectionCallback(

System.Console.WriteLine("Verbindung aufgebaut");
catch (Exception e)

static void MyProvideClientCertificates(X509CertificateCollection clienteCertis)
X509Certificate cert = new X509Certificate("mycert.crt");

static X509Certificate MyCertificateSelectionCallback(X509CertificateCollection clienteCertis, X509Certificate serverCerti, string hostDestino, X509CertificateCollection serverRequestedCertificates)
return clienteCertis[0];

static AsymmetricAlgorithm MyPrivateKeySelectionCallback(X509Certificate certificate, string targetHost)
PrivateKey key =null;
//it is very important that the key has the .pvk format in windows!!!
key = PrivateKey.CreateFromFile("myKey.pvk", "xxx");
catch (CryptographicException ex)

if (key == null)
return null;

return key.RSA;

static bool MyCertificateValidationCallback(X509Certificate certificate, int[] certificateErrors)
* CertVALID = 0,
* CertEXPIRED = -2146762495,//0x800B0101
* CertVALIDITYPERIODNESTING = -2146762494,//0x800B0102
* CertROLE = -2146762493,//0x800B0103
* CertPATHLENCONST = -2146762492,//0x800B0104
* CertCRITICAL = -2146762491,//0x800B0105
* CertPURPOSE = -2146762490,//0x800B0106
* CertISSUERCHAINING = -2146762489,//0x800B0107
* CertMALFORMED = -2146762488,//0x800B0108
* CertUNTRUSTEDROOT = -2146762487,//0x800B0109
* CertCHAINING = -2146762486,//0x800B010A
* CertREVOKED = -2146762485,//0x800B010C
* CertUNTRUSTEDTESTROOT = -2146762484,//0x800B010D
* CertREVOCATION_FAILURE = -2146762483,//0x800B010E
* CertCN_NO_MATCH = -2146762482,//0x800B010F
* CertWRONG_USAGE = -2146762481,//0x800B0110
* CertUNTRUSTEDCA = -2146762480,//0x800B0112

//error: -2146762487, -2146762481
return true;

Monday, March 29, 2010

SSL Renegotiation patch

Hi all!

Albe Laurenz called my attention to a new patch applied to Postgresql servers which allows the administrator to set a value telling server when it will start SSL renegotiations. This parameter also allows you to disable the renegotiation.[1]

Today, I committed a patch which tries to disable SSL Renegotiation on supported postgresql servers, which means, servers which had this patch applied. According to Albe those server versions are: 9.0, 8.4.3, 8.3.10, 8.2.16, 8.1.20, 8.0.24, 7.4.28.

This patch simple calls:

SET ssl_renegotiation_limit=0

as suggested by Albe.

One positive side effect of this modification is that it serves as an workaround
to SSL renegotiation problem with Npgsql.
Today, Npgsql has problems with this, as can be seen on this bug report[2]. Although this patch isn't a solution, at least it makes Npgsql works on long SSL sessions.

If you want to try it out now, please grab latest code from cvs and let us know if you got any problems on our forums:



Sunday, February 14, 2010

Changing build system file and AssemblyInfo

Hi all!

I just committed a change to our file in order to easy
package distribution generation as well as integration with
CruiseControl. Yes, Npgsql is going to have a cruisecontrol server.
More details later.

The biggest change is that our AssemblyInfo.cs file can be generated
automatically. This will be needed in order to generate assembly
versions with a value cruise control server will assign to each build.

So, now, in order to generate a build, you will need to specify the
CCNetLabel property. You don't have to, but if you don't, Npgsql build
will have a version value.

You just need to do:

./ -D:CCNetLabel= ccnet

And it will generate an AssemblyInfo.cs like this:

using System;
using System.Reflection;
using System.Resources;

// ------------------------------------------------------------------------------
// <autogenerated>
// This code was generated by a tool.
// Mono Runtime Version: 2.0.50727.1433
// Changes to this file may cause incorrect behavior and will be lost if
// the code is regenerated.
// </autogenerated>
// ------------------------------------------------------------------------------

[assembly: CLSCompliantAttribute(true)]
[assembly: AssemblyTitleAttribute("Npgsql - .Net Data Provider for PostgreSQL")]
[assembly: AssemblyDescriptionAttribute(".Net Data Provider for PostgreSQL")]
[assembly: AssemblyCompanyAttribute("Npgsql Development Team")]
[assembly: AssemblyProductAttribute("Npgsql")]
[assembly: AssemblyCopyrightAttribute("Copyright © 2002 - 2010 Npgsql Development Team")]
[assembly: AssemblyTrademarkAttribute("")]
[assembly: AssemblyVersionAttribute("")]
[assembly: AssemblyFileVersionAttribute("")]
[assembly: NeutralResourcesLanguageAttribute("en", UltimateResourceFallbackLocation.MainAssembly)]

This ccnet doesn't only generate the AssemblyInfo.cs file. This is in fact done by the createAssemblyInfo which ccnet depends on.

ccnet builds everything. It cleans up the build folder, builds, run the analysis tools and create the
packages. As its name implies, it will be called by cruisecontrol server in order to create the builds.

This is the first shot on this issue, so if you have comments or
suggestions, please let me know.

Thanks in advance.

Wednesday, January 20, 2010

New "articles" section on our Forums

Hi all!

I created an "articles" section on our forums so people can post links to Npgsql, .Net and/or Postgresql related articles which can benefit Npgsql users. This will help users to get a centralized point where they can find valuable information.

Please, check it out here.

Comments and, of course, links are very much welcome.

UPDATE: Alaric Dailey was the first person to post a link to an article about .Net Data Providers. Please, check it out here