> -----Original Message-----
> From: pgsql-odbc-owner@postgresql.org
> [mailto:pgsql-odbc-owner@postgresql.org] On Behalf Of Rainer Bauer
> Sent: 04 November 2005 14:15
> To: pgsql-odbc@postgresql.org
> Subject: Re: [ODBC] Snapshot 08.01.0006 available for testing
>
> "Dave Page" schrieb:
>
> >Well, on further testing, killing off QR->cursor, and then calling
> >QR_Destructor seems to work just fine. With cache sizes from
> 2 to 1000,
> >I'm seeing constant average memory usage. I did see a couple
> of crashes
> >with cache sizes of 100, but when I tried to investigate further, I
> >found I couldn't reproduce them at all, and have run
> successfully ever
> >since.
> >
> >Changes committed to CVS.
>
> No more memory loss here using the CVS version, but 2 bugs
> were introduced by
> the patch:
>
> 1) QR_get_fields() gets called when SC_fetch() is entered.
> However, the QR
> cleanup will free the QResultClass object. And the pointer
> "coli" is no longer
> valid when CI_get_oid() gets called further down.
> I have fixed this by calling QR_get_fields() after the first
> if-statement.
>
> 2) This is basically the same "cache" bug:
> PGAPI_ExtendedFetch() caches the
> stored QResultClass object when the function is entered. But
> after SC_fetch()
> was called, the pointer is no longer valid.
> I have fixed this by calling SC_get_Curres() again after the call to
> SC_fetch().
>
> Side note: The test for self being NULL in QR_Destructor()
> should be the first
> statement. Currently, self->conn is called before the check.
Can you send me a patch for that little lot please?
> Enabling "UsedeclareFetch" slows down my application by a
> factor of 10 (tried
> it with Fetch=100 and Fetch=1000). Yes, _factor_ 10 (loading
> 500 "items" takes
> 30 seconds instead of 3 seconds). The slowdown happens, if
> lots of rows are
> manually fetched by providing the primary key in a "SELECT
> ... WHERE pk=?"
> statement.
> But I guess that "UsedeclareFetch" shouldn't be used in that case?
Yeuch - I never really used it myself, and am very unfamiliar with that
code as I'm sure you gathered. Let's get things basically stable for
now, then when 8.1 etc. is released and Anoop is back next week, we can
start looking at performance etc.
Thanks for your effort.
Regards, Dave.