Devart Forums

I am using the latest release 2.00.2 of PostgreSQLDirect.NET.

When I insert 7.000 records into a table with about 50 fields the "postgres.exe" process that serves the connection goes to a memory usage of 200MB.

Restarting the PostgreSQL service and deleting 7.000 records from the same table brings the memory usage to 90MB.

Updating 7.000 records in the same table brings the memory usage to more than 500MB!!!

Selecting records is no problem.

The process "postgres.exe" never releases the memory until the connection is closed. If you insert, update or delete even more records within the same connection memory usage of "postgres.exe" increases until the system dies when it runs out of available memory.

This is not a bug in "postgres.exe" however. As soon as I switch to another driver like "npgsql" the memory usage of "postgres.exe" stays within the limits that I have configured in "postgresql.conf". (12MB)

Something in the PostgreSQLDirect.NET driver makes the "postgres.exe" process that serves the connection lose memory very rapidly!

Regards,

Joern

P.S.: This could explain why other users have problems when executing many sql commands, see unexpected behavior or can not complete repeated inserts, updates or deletes. At some point the PostgreSQL server just runs out of memory...

Hi,

what is the status on this issue?

I made more tests. I was incorrect when I said that a SELECT statement has no problem. When I select 7.000 records with one SQL query I did not see a problem. But when I issue 7.000 single SELECT statements memory usage of the "postgres.exe" process increases dramatically as with the other statements.

Could it be that you are preparing the SQL statements on the server, then execute the statement, but never release (close) the planned statement and / or the arguments on the server so that memory usage increases with each SQL statement processed?

Regards,

Joern

We reproduced problem and fixed it. Please download the last PostgreSQLDirect .NET version.

Hi,

we tested 2.10 version but the problem is still present in case of multiple update in a transaction with isolation level ReadCommitted

We couldn't reproduce the problem.
Please send us complete small sample to demonstrate it and include script to create server objects.