Thread: Snapshot 08.01.0006 available for testing

I've uploaded a snapshot version of the driver (08.01.0006) to
ftp://ftp.postgresql.org/pub/odbc/versions/snapshots/ for testing.

I hope to release a non-snapshot, production build of the driver within
the next day or so - this snapshot is essentially a release candidate
intended for testing of a couple of last-minute bug fixes applied over
the last few days.

Please take some time to download and test this release, and report any
regressions from prior snapshots as soon as possible.

Thanks, Dave

I've uploaded a snapshot version of the driver (08.01.0006) to
ftp://ftp.postgresql.org/pub/odbc/versions/snapshots/ for testing.

I hope to release a non-snapshot, production build of the driver within
the next day or so - this snapshot is essentially a release candidate
intended for testing of a couple of last-minute bug fixes applied over
the last few days.

Please take some time to download and test this release, and report any
regressions from prior snapshots as soon as possible.

Thanks, Dave

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

               http://archives.postgresql.org

---

From: Josef Springer [mailto:Josef.Springer@JOOPS.COM]
Sent: 03 November 2005 14:45
To: Dave Page
Cc: pgsql-odbc@postgresql.org
Subject: Re: [ODBC] Snapshot 08.01.0006 available for testing

Hi Dave,

contains this snapshot a solution for the UNICODE problem (reading get wrong strings) ?

 All known Unicode problems were fixed a while back. There are now 2 drivers though - the ANSI one should be used unless you specifically require Unicode ODBC support. 

Regards, Dave.

Josef Springer

 -- the software company --

Orlando-di-Lasso Str. 2
D-85640 Putzbrunn

 

---

From: Josef Springer [mailto:Josef.Springer@JOOPS.COM]
Sent: 03 November 2005 14:45
To: Dave Page
Cc: pgsql-odbc@postgresql.org
Subject: Re: [ODBC] Snapshot 08.01.0006 available for testing

Hi Dave,

contains this snapshot a solution for the UNICODE problem (reading get wrong strings) ?

 All known Unicode problems were fixed a while back. There are now 2 drivers though - the ANSI one should be used unless you specifically require Unicode ODBC support. 

Regards, Dave.

---

From: Josef Springer [mailto:Josef.Springer@JOOPS.COM]
Sent: 03 November 2005 15:36
To: Dave Page
Cc: pgsql-odbc@postgresql.org
Subject: Re: [ODBC] Snapshot 08.01.0006 available for testing

Hi Dave,

the setup contains one driver only. Where is the second on to use for UNICODE ?

The setup contains 2 drivers here - 'PostgreSQL Unicode' and 'PostgreSQL ANSI'. Did you uninstall the old one before installing the new?

Regards, Dave.

"Dave Page" schrieb:

>Please take some time to download and test this release, and report any
>regressions from prior snapshots as soon as possible.

I just installed the pgsql and psqlodbc  RC1, but "UseServerSidePrepare" is
still broken.

SQL command: "SELECT col1 FROM table WHERE col2=?"
(Note: col1 is a SERIAL, col2 a VARCHAR).

Bind the input [SQLBindParameter] and output [SQLBindCol] parameter before
calling SQLPrepare().

The following call to SQLExecute() returns SQL_SUCCESS. But the first call to
SQLFetch() produces this error message:
<1> {HY010}(3) Null statement result in PGAPI_ExtendedFetch.

If I set "UseServerSidePrepare" to "0", everything works fine.

Using the debugger, I found out that Exec_with_parameters_resolved() will not
call SC_set_Curres(), because stmt->inaccurate_result and
conn->connInfo.disallow_premature are both FALSE.

However, the connections string I use (see below) did work with the "old"
psqlodbc driver 8.00.0102 that I used initially.

Let me know, if I can do anything else to help tracking down this bug.

Rainer

PS: This is my connection setting:
A0=0;A1=6.4;A2=0;A3=0;A4=0;A5=0;A6=;A7=100;A8=8192;A9=0;
B0=254;B1=4095;B2=0;B3=0;B4=1;B5=1;B6=0;B7=1;B8=0;B9=0;
C0=0;C1=0;C2=dd_;C3=0;C4=0;
Lie=0;LFConversion=0;TrueIsMinus1=0;BI=0;ByteaAsLongVarBinary=1;UseServerSidePrepare=1;LowerCaseIdentifier=0;

> -----Original Message-----
> From: pgsql-odbc-owner@postgresql.org
> [mailto:pgsql-odbc-owner@postgresql.org] On Behalf Of Rainer Bauer
> Sent: 03 November 2005 15:50
> To: pgsql-odbc@postgresql.org
> Subject: Re: [ODBC] Snapshot 08.01.0006 available for testing
>
> "Dave Page" schrieb:
>
> >Please take some time to download and test this release, and
> report any
> >regressions from prior snapshots as soon as possible.
>
> I just installed the pgsql and psqlodbc  RC1, but
> "UseServerSidePrepare" is
> still broken.
>
> SQL command: "SELECT col1 FROM table WHERE col2=?"
> (Note: col1 is a SERIAL, col2 a VARCHAR).
>
> Bind the input [SQLBindParameter] and output [SQLBindCol]
> parameter before
> calling SQLPrepare().
>
> The following call to SQLExecute() returns SQL_SUCCESS. But
> the first call to
> SQLFetch() produces this error message:
> <1> {HY010}(3) Null statement result in PGAPI_ExtendedFetch.

Works perfectly here. When you say you are using RC1, do you mean the
driver that can bundled with PostgreSQL 8.1 RC1? If so, that is
08.01.0005. The Prepare/Fetch fixes are in 08.01.0006.

Regards, Dave.

"Dave Page" wrote:

>> SQL command: "SELECT col1 FROM table WHERE col2=?"
>> (Note: col1 is a SERIAL, col2 a VARCHAR).
>>
>> Bind the input [SQLBindParameter] and output [SQLBindCol]
>> parameter before
>> calling SQLPrepare().
>>
>> The following call to SQLExecute() returns SQL_SUCCESS. But
>> the first call to
>> SQLFetch() produces this error message:
>> <1> {HY010}(3) Null statement result in PGAPI_ExtendedFetch.
>
>Works perfectly here. When you say you are using RC1, do you mean the
>driver that can bundled with PostgreSQL 8.1 RC1? If so, that is
>08.01.0005. The Prepare/Fetch fixes are in 08.01.0006.

No. I am using the 08.01.0006 driver with PostgreSQL 8.1 RC1.

The PostgreSQL server is running won a w2k server.
The client is running on a Win98 machine.

Rainer

> -----Original Message-----
> From: pgsql-odbc-owner@postgresql.org
> [mailto:pgsql-odbc-owner@postgresql.org] On Behalf Of Rainer Bauer
> Sent: 03 November 2005 16:20
> To: pgsql-odbc@postgresql.org
> Subject: Re: [ODBC] Snapshot 08.01.0006 available for testing
>
> "Dave Page" wrote:
>
> >> SQL command: "SELECT col1 FROM table WHERE col2=?"
> >> (Note: col1 is a SERIAL, col2 a VARCHAR).
> >>
> >> Bind the input [SQLBindParameter] and output [SQLBindCol]
> >> parameter before
> >> calling SQLPrepare().
> >>
> >> The following call to SQLExecute() returns SQL_SUCCESS. But
> >> the first call to
> >> SQLFetch() produces this error message:
> >> <1> {HY010}(3) Null statement result in PGAPI_ExtendedFetch.
> >
> >Works perfectly here. When you say you are using RC1, do you mean the
> >driver that can bundled with PostgreSQL 8.1 RC1? If so, that is
> >08.01.0005. The Prepare/Fetch fixes are in 08.01.0006.
>
> No. I am using the 08.01.0006 driver with PostgreSQL 8.1 RC1.
>
> The PostgreSQL server is running won a w2k server.
> The client is running on a Win98 machine.

Sorry - when I first read both messages I somehow managed to parse
ServerSidePrepare as UsedeclareFetch :-(

Yes, it does seem to be broken - the earlier fixes were for Use
Declare/Fetch, so I'm not overly surprised it remains broken.

I'll look into it, however given that it's not a widely used option (and
isn't documented either), I'm still inclined to release 08.01.whatever
even if we can't figure out the correct fix in time. It's definitely a
less broken driver than the current stable release.

Regards, Dave.

"Dave Page" wrote:

>> >> SQL command: "SELECT col1 FROM table WHERE col2=?"
>> >> (Note: col1 is a SERIAL, col2 a VARCHAR).
>> >>
>> >> Bind the input [SQLBindParameter] and output [SQLBindCol]
>> >> parameter before
>> >> calling SQLPrepare().
>> >>
>> >> The following call to SQLExecute() returns SQL_SUCCESS. But
>> >> the first call to
>> >> SQLFetch() produces this error message:
>> >> <1> {HY010}(3) Null statement result in PGAPI_ExtendedFetch.

(...)

>Sorry - when I first read both messages I somehow managed to parse
>ServerSidePrepare as UsedeclareFetch :-(
>
>Yes, it does seem to be broken - the earlier fixes were for Use
>Declare/Fetch, so I'm not overly surprised it remains broken.
>
>I'll look into it, however given that it's not a widely used option (and
>isn't documented either), I'm still inclined to release 08.01.whatever
>even if we can't figure out the correct fix in time. It's definitely a
>less broken driver than the current stable release.

That's no problem. The 08.01.006 driver is working without
"ServerSidePrepare"; it's just a performance issue.

However, I just turned on "UsedeclareFetch" to see if it works. There are
_lots_ of memory leakages (in repeating patterns) when my program exits (see
below). They all vanish if "UsedeclareFetch" is disabled. Seems like this is
related to memory not freed in class QResultClass.

Apart from that it seems to work, although I haven't done any stress tests.
But I might find some time tomorrow to check it more thoroughly.

Rainer


 Data: <ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ> FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
 Data: <        > 00 00 00 00 00 00 00 00
 Data: <@ @   ÿ > 40 00 40 00 01 00 FF 0F
 Data: <                > 13 00 00 00 13 00 00 00 12 00 00 00 19 00 00 00
 Data: <@vC  vC ÀuC €uC > 40 76 43 01 00 76 43 01 C0 75 43 01 80 75 43 01
 Data: <  ÍÍ0xC ðwC  wC > 04 00 CD CD 30 78 43 01 F0 77 43 01 00 77 43 01
 Data: <pxC 0uC xÜ9     > 70 78 43 01 30 75 43 01 78 DC 39 01 00 00 00 00
 Data: <ÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ> CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD
 Data: <SQL_CUR01430070 > 53 51 4C 5F 43 55 52 30 31 34 33 30 30 37 30 00
 Data: <fetch 100 in SQL> 66 65 74 63 68 20 31 30 30 20 69 6E 20 53 51 4C
 Data: <coalesce > 63 6F 61 6C 65 73 63 65 00
 Data: <relkind > 72 65 6C 6B 69 6E 64 00
 Data: <nspname > 6E 73 70 6E 61 6D 65 00
 Data: <relname > 72 65 6C 6E 61 6D 65 00
 Data: <ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ> FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
 Data: <        > 00 00 00 00 00 00 00 00
 Data: <@ @   ÿ > 40 00 40 00 01 00 FF 0F
 Data: <                > 13 00 00 00 13 00 00 00 12 00 00 00 19 00 00 00
 Data: < zC àyC  yC `yC > 20 7A 43 01 E0 79 43 01 A0 79 43 01 60 79 43 01
 Data: <  Í̀ C À{C €{C > 04 00 CD CD 80 0B 43 01 C0 7B 43 01 80 7B 43 01
 Data: <€ C  yC xÜ9     > 80 7F 43 01 10 79 43 01 78 DC 39 01 00 00 00 00
 Data: <ÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ> CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD
 Data: <SQL_CUR01430DC0 > 53 51 4C 5F 43 55 52 30 31 34 33 30 44 43 30 00
 Data: <fetch 100 in SQL> 66 65 74 63 68 20 31 30 30 20 69 6E 20 53 51 4C
 Data: <coalesce > 63 6F 61 6C 65 73 63 65 00
 Data: <relkind > 72 65 6C 6B 69 6E 64 00
 Data: <nspname > 6E 73 70 6E 61 6D 65 00
 Data: <relname > 72 65 6C 6E 61 6D 65 00

Hi,

About one memory leak ...

(Note that if you interpret the row numbers, you must decrement
the row number by about 3, because each file has at top:
#ifdef DMALLOC
#include "dmalloc.h"
#endif

My test case was to insert 100 rows and then fetched them from the database.
I used SQLExecDirect() and SQLGetData().
No SQLBindCol and no SQLBindParameter.

Here are the results of the memory leaks:


...
1131043728: 2314: not freed: '0x40489f88|s1' (5 bytes) from
'columninfo.c:115'
1131043728: 2314: not freed: '0x40489fa8|s3' (18 bytes) from 'qresult.c:379'
1131043728: 2314: not freed: '0x40489fc8|s3' (16 bytes) from 'qresult.c:412'
1131043728: 2314: not freed: '0x40489fe8|s1' (5 bytes) from
'columninfo.c:115'
1131043728: 2314: total-size count source
1131043728: 2314: 5916 51 qresult.c:98
1131043728: 2314: 1479 51 qresult.c:241
1131043728: 2314: 1224 51 columninfo.c:30
1131043728: 2314: 918 51 qresult.c:379
1131043728: 2314: 816 51 qresult.c:412
1131043728: 2314: 254 51 columninfo.c:115
1131043728: 2314: 204 51 columninfo.c:102
1131043728: 2314: 204 51 columninfo.c:99
1131043728: 2314: 204 51 columninfo.c:97
1131043728: 2314: 102 51 columninfo.c:100
1131043728: 2314: 102 51 columninfo.c:101

1131043728: 2314: 11423 561 Total of 11

So 51 is caused from 100/2+1 fetch cursor calls.

Problem:
QR_Constructor is used for every new backend fetch.
Original qres result will be forgotten in
statement.c: 939 - 3 = 936

Unfortunately QR_Destructor would close the cursor,
which is bad for Declare/Fetch.

I tried something yesterday for that, but my trial crashed.
I don't know why.

Here is a GDB stack trace.
#3 is the important one.
There qres will be forgotten with
SC_set_Result(self,res);



(gdb) i s
#0 QR_Constructor () at qresult.c:97
#1 0x4033e1b2 in LIBPQ_execute_query (self=0x4038e008, query=0xbffff4b0
"fetch 2 in SQL_CUR0x40394808")
at connection.c:1776
#2 0x4033d623 in CC_send_query (self=0x4038e008, query=0xbffff4b0 "fetch
2 in SQL_CUR0x40394808", qi=0xbffff4a0, flag=0)
at connection.c:1479
#3 0x4036185e in SC_fetch (self=0x40394808) at statement.c:937
#4 0x4035733b in PGAPI_ExtendedFetch (hstmt=0x40394808, fFetchType=1,
irow=0, pcrow=0x0, rgfRowStatus=0x0,
bookmark_offset=0, rowsetSize=1) at results.c:1487
#5 0x403679cf in SQLFetch (StatementHandle=0x40394808) at odbcapi.c:344
#6 0x40046cb2 in SQLFetch () from /usr/lib/libodbc.so.1
#7 0x0804926f in main (argc=1, argv=0xbffff834) at TestQuery.c:207

Regards, Marko

Rainer Bauer wrote:

>"Dave Page" wrote:
>
>
>
>>>>>SQL command: "SELECT col1 FROM table WHERE col2=?"
>>>>>(Note: col1 is a SERIAL, col2 a VARCHAR).
>>>>>
>>>>>Bind the input [SQLBindParameter] and output [SQLBindCol]
>>>>>parameter before
>>>>>calling SQLPrepare().
>>>>>
>>>>>The following call to SQLExecute() returns SQL_SUCCESS. But
>>>>>the first call to
>>>>>SQLFetch() produces this error message:
>>>>><1> {HY010}(3) Null statement result in PGAPI_ExtendedFetch.
>>>>>
>>>>>
>
>(...)
>
>
>
>>Sorry - when I first read both messages I somehow managed to parse
>>ServerSidePrepare as UsedeclareFetch :-(
>>
>>Yes, it does seem to be broken - the earlier fixes were for Use
>>Declare/Fetch, so I'm not overly surprised it remains broken.
>>
>>I'll look into it, however given that it's not a widely used option (and
>>isn't documented either), I'm still inclined to release 08.01.whatever
>>even if we can't figure out the correct fix in time. It's definitely a
>>less broken driver than the current stable release.
>>
>>
>
>That's no problem. The 08.01.006 driver is working without
>"ServerSidePrepare"; it's just a performance issue.
>
>However, I just turned on "UsedeclareFetch" to see if it works. There are
>_lots_ of memory leakages (in repeating patterns) when my program exits (see
>below). They all vanish if "UsedeclareFetch" is disabled. Seems like this is
>related to memory not freed in class QResultClass.
>
>Apart from that it seems to work, although I haven't done any stress tests.
>But I might find some time tomorrow to check it more thoroughly.
>
>Rainer
>
>
> Data: <ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ> FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
> Data: <        > 00 00 00 00 00 00 00 00
> Data: <@ @   ÿ > 40 00 40 00 01 00 FF 0F
> Data: <                > 13 00 00 00 13 00 00 00 12 00 00 00 19 00 00 00
> Data: <@vC  vC ÀuC €uC > 40 76 43 01 00 76 43 01 C0 75 43 01 80 75 43 01
> Data: <  ÍÍ0xC ðwC  wC > 04 00 CD CD 30 78 43 01 F0 77 43 01 00 77 43 01
> Data: <pxC 0uC xÜ9     > 70 78 43 01 30 75 43 01 78 DC 39 01 00 00 00 00
> Data: <ÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ> CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD
> Data: <SQL_CUR01430070 > 53 51 4C 5F 43 55 52 30 31 34 33 30 30 37 30 00
> Data: <fetch 100 in SQL> 66 65 74 63 68 20 31 30 30 20 69 6E 20 53 51 4C
> Data: <coalesce > 63 6F 61 6C 65 73 63 65 00
> Data: <relkind > 72 65 6C 6B 69 6E 64 00
> Data: <nspname > 6E 73 70 6E 61 6D 65 00
> Data: <relname > 72 65 6C 6E 61 6D 65 00
> Data: <ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ> FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
> Data: <        > 00 00 00 00 00 00 00 00
> Data: <@ @   ÿ > 40 00 40 00 01 00 FF 0F
> Data: <                > 13 00 00 00 13 00 00 00 12 00 00 00 19 00 00 00
> Data: < zC àyC  yC `yC > 20 7A 43 01 E0 79 43 01 A0 79 43 01 60 79 43 01
> Data: <  ÍÍ€ C À{C €{C > 04 00 CD CD 80 0B 43 01 C0 7B 43 01 80 7B 43 01
> Data: <€ C  yC xÜ9     > 80 7F 43 01 10 79 43 01 78 DC 39 01 00 00 00 00
> Data: <ÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ> CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD
> Data: <SQL_CUR01430DC0 > 53 51 4C 5F 43 55 52 30 31 34 33 30 44 43 30 00
> Data: <fetch 100 in SQL> 66 65 74 63 68 20 31 30 30 20 69 6E 20 53 51 4C
> Data: <coalesce > 63 6F 61 6C 65 73 63 65 00
> Data: <relkind > 72 65 6C 6B 69 6E 64 00
> Data: <nspname > 6E 73 70 6E 61 6D 65 00
> Data: <relname > 72 65 6C 6E 61 6D 65 00
>
>
>---------------------------(end of broadcast)---------------------------
>TIP 5: don't forget to increase your free space map settings
>
>
>

> -----Original Message-----
> From: pgsql-odbc-owner@postgresql.org
> [mailto:pgsql-odbc-owner@postgresql.org] On Behalf Of Marko Ristola
> Sent: 03 November 2005 19:22
> To: Rainer Bauer
> Cc: pgsql-odbc@postgresql.org
> Subject: Re: [ODBC] Snapshot 08.01.0006 available for testing
>
> Problem:
> QR_Constructor is used for every new backend fetch.
> Original qres result will be forgotten in
> statement.c: 939 - 3 = 936

Yes - I originally tried to kill the qres, but that clobbered something
and crashed, so I just killed the tuplelist for the time being.

> Unfortunately QR_Destructor would close the cursor,
> which is bad for Declare/Fetch.

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.

Regards, Dave.

---

From: Josef Springer [mailto:Josef.Springer@JOOPS.COM]
Sent: 04 November 2005 08:56
To: Dave Page
Cc: pgsql-odbc@postgresql.org
Subject: Re: [ODBC] Snapshot 08.01.0006 available for testing

Hi Dave,

i started the setup on an PostgrSQL-free system.
 

---

From: Josef Springer [mailto:Josef.Springer@JOOPS.COM]
Sent: 03 November 2005 15:36
To: Dave Page
Cc: pgsql-odbc@postgresql.org
Subject: Re: [ODBC] Snapshot 08.01.0006 available for testing

Hi Dave,

the setup contains one driver only. Where is the second on to use for UNICODE ?

Dave Page wrote:
> The setup contains 2 drivers here - 'PostgreSQL Unicode' and
> 'PostgreSQL ANSI'. Did you uninstall the old one before installing
> the new?

Out of curiosity, why would it be called "ANSI"?  Is this particular
version standardized by ANSI? :)

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

> -----Original Message-----
> From: Peter Eisentraut [mailto:peter_e@gmx.net]
> Sent: 04 November 2005 10:06
> To: Dave Page
> Cc: pgsql-odbc@postgresql.org
> Subject: Re: [ODBC] Snapshot 08.01.0006 available for testing
>
> Dave Page wrote:
> > The setup contains 2 drivers here - 'PostgreSQL Unicode' and
> > 'PostgreSQL ANSI'. Did you uninstall the old one before installing
> > the new?
>
> Out of curiosity, why would it be called "ANSI"?  Is this particular
> version standardized by ANSI? :)

Just following the convention set by Microsoft in the docs -
strings/functions/applications are considered to be either Unicode or
ANSI.

See
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/odbc/ht
m/odbcunicode_applications.asp for example.

Regards, Dave

---

From: Josef Springer [mailto:Josef.Springer@JOOPS.COM]
Sent: 04 November 2005 08:56
To: Dave Page
Cc: pgsql-odbc@postgresql.org
Subject: Re: [ODBC] Snapshot 08.01.0006 available for testing

Hi Dave,

i started the setup on an PostgrSQL-free system.
 

---

From: Josef Springer [mailto:Josef.Springer@JOOPS.COM]
Sent: 04 November 2005 10:54
To: Dave Page
Cc: pgsql-odbc@postgresql.org
Subject: Re: [ODBC] Snapshot 08.01.0006 available for testing

Hi Dave,

 i opened psqlodbc-08_01_0006.zip and startet the only included setup psqlodbc.msi.
The installation tree contains:
psqlODBC
---> ODBC Driver
---> Documentation 

 

"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

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

"Dave Page" wrote:

>Can you send me a patch for that little lot please?

See below, I hope I did everything right. I haven't patched QR_Destructor()
though.

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

Sounds good.

Rainer

===================================================================
RCS file: /cvsroot/psqlodbc/psqlodbc/results.c,v
retrieving revision 1.83
diff -u -r1.83 results.c
--- results.c    3 Nov 2005 12:05:13 -0000    1.83
+++ results.c    4 Nov 2005 14:07:24 -0000
@@ -1482,6 +1482,7 @@
     {
         stmt->bind_row = i;        /* set the binding location */
         result = SC_fetch(stmt);
+        res = SC_get_Curres(stmt);
 #ifdef    DRIVER_CURSOR_IMPLEMENT
         if (SQL_SUCCESS_WITH_INFO == result && 0 ==
stmt->last_fetch_count && res->keyset)
         {

***** CVS exited normally with code 1 *****

===================================================================
RCS file: /cvsroot/psqlodbc/psqlodbc/statement.c,v
retrieving revision 1.106
diff -u -r1.106 statement.c
--- statement.c    3 Nov 2005 22:31:16 -0000    1.106
+++ statement.c    4 Nov 2005 13:39:52 -0000
@@ -922,7 +922,6 @@
     ConnInfo   *ci = &(SC_get_conn(self)->connInfo);

     self->last_fetch_count = self->last_fetch_count_include_ommitted = 0;
-    coli = QR_get_fields(res);    /* the column info */

     /* Issue the fetch query here in case of declare fetch for subsequent
rows */
     if (SC_is_fetchcursor(self) && ((self->currTuple %
ci->drivers.fetch_max) >= QR_get_num_total_tuples(res) - 1))
@@ -930,28 +929,44 @@
         qi.result_in = NULL;
         qi.cursor = self->cursor_name;
         qi.row_size = ci->drivers.fetch_max;
-        sprintf(fetch, "fetch %d in %s",ci->drivers.fetch_max ,
self->cursor_name);

-

-        /* Cleanup the QR. We need to kill off the cursor first, or this will
crash */

-        if (self->result->cursor)

-        {

-            free(self->result->cursor);

-              self->result->cursor = NULL;

-        }

-

-        if (self->result)

-        {

-            QR_Destructor(self->result);

-            self->result = NULL;

-        }

-

+        sprintf(fetch, "fetch %d in %s",ci->drivers.fetch_max ,
self->cursor_name);
+
+
+
+        /* Cleanup the QR. We need to kill off the cursor first, or this will
crash */
+
+        if (self->result->cursor)
+
+        {
+
+            free(self->result->cursor);
+
+              self->result->cursor = NULL;
+
+        }
+
+
+
+        if (self->result)
+
+        {
+
+            QR_Destructor(self->result);
+
+            self->result = NULL;
+
+        }
+
+
+
         /* Finished cleanup */
-

-        res = CC_send_query(self->hdbc, fetch, &qi, qflag);
-
+
+
+        res = CC_send_query(self->hdbc, fetch, &qi, qflag);
         SC_set_Result(self,res);
     }

+    coli = QR_get_fields(res);    /* the column info */
     mylog("manual_result = %d, use_declarefetch = %d\n",
self->manual_result, ci->drivers.use_declarefetch);

     if (self->manual_result)

***** CVS exited normally with code 1 *****

> -----Original Message-----
> From: pgsql-odbc-owner@postgresql.org
> [mailto:pgsql-odbc-owner@postgresql.org] On Behalf Of Rainer Bauer
> Sent: 04 November 2005 14:56
> To: pgsql-odbc@postgresql.org
> Subject: Re: [ODBC] Snapshot 08.01.0006 available for testing
>
> "Dave Page" wrote:
>
> >Can you send me a patch for that little lot please?
>
> See below, I hope I did everything right.

More or less :-). I'd only ask that in future, please include patches as
attachments to stop mailers mangling them, and use diff -c format as
it's more robust (and readable).

> I haven't patched
> QR_Destructor()
> though.

Done. Thanks for the testing and bug fixes. All committed. :-)

Regards, Dave.

"Dave Page" wrote:

>> See below, I hope I did everything right.
>
>More or less :-). I'd only ask that in future, please include patches as
>attachments to stop mailers mangling them, and use diff -c format as
>it's more robust (and readable).

I will do that.

Rainer

Hi.

I tested memory behaviour again.

Memory behaviour is very good.
Now my test programs use constant memory:

Quite an improvement from 130M into 4.8M.
Dmalloc didn't report any memory leaks.

Regards,
Marko Ristola

Dave Page wrote:

>
>
>
>
>>-----Original Message-----
>>From: pgsql-odbc-owner@postgresql.org
>>[mailto:pgsql-odbc-owner@postgresql.org] On Behalf Of Rainer Bauer
>>Sent: 04 November 2005 14:56
>>To: pgsql-odbc@postgresql.org
>>Subject: Re: [ODBC] Snapshot 08.01.0006 available for testing
>>
>>"Dave Page" wrote:
>>
>>
>>
>>>Can you send me a patch for that little lot please?
>>>
>>>
>>See below, I hope I did everything right.
>>
>>
>
>More or less :-). I'd only ask that in future, please include patches as
>attachments to stop mailers mangling them, and use diff -c format as
>it's more robust (and readable).
>
>
>
>>I haven't patched
>>QR_Destructor()
>>though.
>>
>>
>
>Done. Thanks for the testing and bug fixes. All committed. :-)
>
>Regards, Dave.
>
>---------------------------(end of broadcast)---------------------------
>TIP 5: don't forget to increase your free space map settings
>
>

Peter Eisentraut <peter_e@gmx.net> writes:

> Dave Page wrote:
>> The setup contains 2 drivers here - 'PostgreSQL Unicode' and
>> 'PostgreSQL ANSI'. Did you uninstall the old one before installing
>> the new?
>
> Out of curiosity, why would it be called "ANSI"?  Is this particular
> version standardized by ANSI? :)

<http://blogs.msdn.com/oldnewthing/archive/2004/05/31/144893.aspx>

<http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnw32dev/html/ora_apiprog6_topic1.asp>

 "The term "ANSI" as used to signify Windows code pages is a
 historical reference, but is nowadays a misnomer that continues to
 persist in the Windows community."

And "unicode" actually means UCS-2 or UTF-16 (depending on the platform).

---

From: Josef Springer [mailto:Josef.Springer@JOOPS.COM]
Sent: 08 November 2005 10:20
To: Dave Page
Subject: Re: [ODBC] Snapshot 08.01.0006 available for testing

Hi Dave,

i have installed two versions of the ODBC drivers:
(8.01.00.03 / 8.3.05)
and the new one (8.00.01.01 / 3.5.05, psqlodbclibpq.dll).

If i install the new one with the ODBC manager, there is no UNICODE option and the ODBC manager contains only this one driver.
Running on w2k behaves same wrong: Reveived column strings must be encoded to UTF-8 by hand
 

---

From: Josef Springer [mailto:Josef.Springer@JOOPS.COM]
Sent: 08 November 2005 16:26
To: Dave Page
Subject: Re: [ODBC] Snapshot 08.01.0006 available for testing

Hi Dave,

i downloaded 08.01.0100 and installed the Unicode variant. The behaviour is unchanged.

Sending string with german vovels resulted in the error:
Error while executing the query;
ERROR:  Unicode characters greater than or equal to 0x10000 are not supported
ODBC call was:    executeExternal
SQL state:        S1000'

If i convert the string to UTF-8, before sending, it works.
  
Reveiving strings with german vovels works fine.
 

---

From: Josef Springer [mailto:Josef.Springer@JOOPS.COM]
Sent: 09 November 2005 08:24
To: Dave Page
Cc: pgsql-odbc@postgresql.org
Subject: Re: [ODBC] Snapshot 08.01.0006 available for testing

Hi Dave,

i tried the ANSI driver allready. It did not work in any case !

Regards,
Josef

Dave Page wrote:

---

From: Josef Springer [mailto:Josef.Springer@JOOPS.COM]
Sent: 08 November 2005 16:26
To: Dave Page
Subject: Re: [ODBC] Snapshot 08.01.0006 available for testing

Hi Dave,

i downloaded 08.01.0100 and installed the Unicode variant. The behaviour is unchanged.

Sending string with german vovels resulted in the error:
Error while executing the query;
ERROR:  Unicode characters greater than or equal to 0x10000 are not supported
ODBC call was:    executeExternal
SQL state:        S1000'

If i convert the string to UTF-8, before sending, it works.
  
Reveiving strings with german vovels works fine.
 

---

From: Josef Springer [mailto:Josef.Springer@JOOPS.COM]
Sent: 09 November 2005 10:03
To: Dave Page
Subject: Re: [ODBC] Snapshot 08.01.0006 available for testing

I tested  08.01.0100 and the driver included in the PostgreSQL 8.0.1 distribution only.
Whats the 07 series ?
 

Hi Paul,

For now, i use a classic connectionstring to ODBC and
PostgreSQL without any trouble.
I'm able to create users, database, tables without
issues.

I'm under VS.net 2005 and NET v2.0.

Maileen

--- Leendert Paul Diterwich <paulditerwich@gmail.com>
wrote:

> I'm trying to autogenerate insert,update and
> deletecommands. Which worked
> perfectly in VS beta 2 but know it refuses to do so.
> Has anyone had the same
> experiences or perhaps workarounds in f.e. modifying
> the connection string?
>
>
>
> Regards,
>
>
>
> Paul
>
>





__________________________________
Yahoo! Mail - PC Magazine Editors' Choice 2005
http://mail.yahoo.com

---

From: Josef Springer [mailto:Josef.Springer@JOOPS.COM]
Sent: 09 November 2005 10:03
To: Dave Page
Subject: Re: [ODBC] Snapshot 08.01.0006 available for testing

I tested  08.01.0100 and the driver included in the PostgreSQL 8.0.1 distribution only.
Whats the 07 series ?
 

---

From: Josef Springer [mailto:Josef.Springer@JOOPS.COM]
Sent: 10 November 2005 09:13
To: Dave Page
Cc: pgsql-odbc@postgresql.org
Subject: Re: [ODBC] Snapshot 08.01.0006 available for testing

Hi Dave,

my general situation is:
We developed and distribute a standard BPM-System. The documentation for the user describes how to load and install PostgreSQL. We must make the steps to use PostgreSQL easy as much as possible ! To write "load PostgreSQL 8.0.1 and ODBC driver 7...." seems to fussy for me. How are the plans of the community ? Will a version be distributed with a working ODBC driver for UNICODE ?

p.s. The standard distribution 8.0.1 works on Windows-XP platforms without fine. The encoding problems arise on w2k platforms only ! 

 

---

From: Josef Springer [mailto:Josef.Springer@JOOPS.COM]
Sent: 10 November 2005 09:13
To: Dave Page
Cc: pgsql-odbc@postgresql.org
Subject: Re: [ODBC] Snapshot 08.01.0006 available for testing

Hi Dave,

my general situation is:
We developed and distribute a standard BPM-System. The documentation for the user describes how to load and install PostgreSQL. We must make the steps to use PostgreSQL easy as much as possible ! To write "load PostgreSQL 8.0.1 and ODBC driver 7...." seems to fussy for me. How are the plans of the community ? Will a version be distributed with a working ODBC driver for UNICODE ?

p.s. The standard distribution 8.0.1 works on Windows-XP platforms without fine. The encoding problems arise on w2k platforms only !  

 

---

From: Josef Springer [ mailto:Josef.Springer@JOOPS.COM ]
Sent: 10 November 2005 09:13
To: Dave Page
Cc: pgsql-odbc@postgresql.org
Subject: Re: [ODBC] Snapshot 08.01.0006 available for testing

Hi Dave,

my general situation is:
We developed and distribute a standard BPM-System. The documentation for the user describes how to load and install PostgreSQL. We must make the steps to use PostgreSQL easy as much as possible ! To write "load PostgreSQL 8.0.1 and ODBC driver 7...." seems to fussy for me. How are the plans of the community ? Will a version be distributed with a working ODBC driver for UNICODE ?

p.s. The standard distribution 8.0.1 works on Windows-XP platforms without fine. The encoding problems arise on w2k platforms only !