I often get this error with the connectionpooling set to true...
current transaction is aborted, commands ignored until..
however when i change it to false the error vanishes. I need to have the pooling on

Please describe the problem in detail.
Send us small test project if possible to reproduce the problem; it is
desirable to use 'test' schema objects, otherwise include definition of
your own database objects. Do not use third party components.
If it is impossible for you to create test project please send us a piece of
your code where the error occurs.

We have the same problem, using Win 2003, 8.1+ versions of Postgres and Corelab driver 2.55.
I assume that the problem starts when there is an aborted transaction, like when trying to insert a record with existing PK, and no rollback or commit follows. That connection is returned to the pool and new clients start using it, in aborted state. If there are 20 connections in the pool, the effect is that random 5% of requests for a fresh connection return the error in the title.
I suppose that this behaviour is not normal since I would expect to get a connection from the pool with no previous client's state.
I could not find a way to detect the rogue connection when requesting a fresh one. There is no connection's property saying if it is in transaction state. I tried writing some other data to the in-transaction connection (like specific timeout), but it is not available after recycling (that behaviour is correct).
The solution we use is to rollback every new connection and that solved the problem in a not so elegant way.

Please send me a small test project to reproduce the problem. It is
desirable to use 'test' schema objects, otherwise include definition of your own database objects.
Use e-mail address provided in the Readme file.
Do not use third party components.

Is it not easy to make a small project. We use our own framework with meta-generated C# code. I am afraid it will take days to extract a small project from that all. Besides, I've never seen that message on my development PC. I suppose I should have tried simulating a bigger workload. However, our production web servers used to report 50+ such error messages daily before rollback-all cure was used. After that single line was added, no such message has ever been reported.
We do not use third party components. Not even MS server controls.

Connections' destructor includes:
...
cn.Dispose();
...
We tried .Close() but it did not help. I suppose that only an explicit call to a GC would solve the problem, but also by removing performance advantages of the connection pool.

I tried to use version 3.0 but I got the message "Could not load type CoreLab.Common.DbConnection from assembly CoreLab.PostgreSql, Version=3.0.8.0,..." when trying to open a connection.
So, I cannot test it. I use .Net 1.1 version and Windows 2003.