Re: 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.

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?

Rainer