Skip site navigation (1) Skip section navigation (2)

Re: psqlodbc 07.03.0261 Memory Leak?

From: "Daniel Holm" <Daniel(dot)Holm(at)interworksinc(dot)com>
To: <pgsql-odbc(at)postgresql(dot)org>
Subject: Re: psqlodbc 07.03.0261 Memory Leak?
Date: 2006-03-26 20:27:08
Message-ID: 22CFEEFF5C5D60429D6B0572DB26625928FD7C@iwsbsrv1.InterWorksok.com (view raw or flat)
Thread:
Lists: pgsql-odbc
One other thing I didn't mention, is that I set the cache size to 1 for
this operation.

-----Original Message-----
From: Daniel Holm 
Sent: Sunday, March 26, 2006 1:45 PM
To: pgsql-odbc(at)postgresql(dot)org
Subject: psqlodbc 07.03.0261 Memory Leak?

I'm copying data from a table of over 100,000 rows in Microsoft SQL
server. This table contains a column of type "Image". I am using a DTS
package and have mapped that column over to a column of type "bytea".

The stable 8.x driver won't even begin to copy the data, so I have
attempted to use the experimental driver (07.03.0261) to do my copying.
It works great, except for the excessive memory usage. The memory usage
constantly climbs throughout the execution. I can run about 2000 rows
quickly - then it slows down considerably (probably switches to using
virtual memory). Around 7,000 rows it finally dies and prints this for
the first error:
"Query buffer allocate error in copy_statement_with_parameters"
And then second:
"Out of memory in PGAPI_PutData (3)"

1) Is there anything more I can provide to assist in locating the cause
of this leak?

2) Is there a better way to transfer these 100,000 rows from Microsoft
SQL to Postgres 8.1 instead of using a DTS package? The memory issue
could be from there.

Thanks in advance for any assistance; you all have been wonderful so far
in this process!

-Daniel Holm

Responses

pgsql-odbc by date

Next:From: ├ůsmund Kveim LieDate: 2006-03-27 07:37:53
Subject: Re: [Fwd: Re: MaxLongVarChar and new lines in text]
Previous:From: Daniel HolmDate: 2006-03-26 19:44:56
Subject: psqlodbc 07.03.0261 Memory Leak?

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group