|
Home > Archive > PostgeSQL ODBC > November 2005 > Snapshot 08.01.0006 available for testing
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Snapshot 08.01.0006 available for testing
|
|
| Dave Page 2005-11-03, 8:24 pm |
| 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
| |
| Dave Page 2005-11-03, 8:24 pm |
|
____________________
____________
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.
| |
| Dave Page 2005-11-03, 8:24 pm |
|
____________________
____________
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.
| |
| Rainer Bauer 2005-11-03, 8:24 pm |
| "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 & #91;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
;ByteaAsLongVarBinar
y=1;UseServerSidePre
pare=1;LowerCaseIden
tifier=0;
| |
| Dave Page 2005-11-03, 8:24 pm |
|
> -----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:
>
> report any
>
> 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 & #91;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.
---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend
| |
| Rainer Bauer 2005-11-03, 8:24 pm |
| "Dave Page" wrote:
>
>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
| |
| Dave Page 2005-11-03, 8:24 pm |
|
> -----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:
>
>
> 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.
---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
| |
| Rainer Bauer 2005-11-03, 8:24 pm |
| "Dave Page" wrote:
(...)
[color=darkred]
>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
| |
| Marko Ristola 2005-11-03, 8:24 pm |
|
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,r
es);
(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=0x4
0394808) 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:
>
>
>
>
>(...)
>
>
>
>
>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
>
>
>
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
| |
| Dave Page 2005-11-03, 8:24 pm |
|
> -----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.
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql
.org so that your
message can get through to the mailing list cleanly
| |
| Dave Page 2005-11-04, 3:23 am |
|
____________________
____________
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.
OK, what files are in the installation directory?
Regards, Dave
| |
| Josef Springer 2005-11-04, 7:23 am |
| Hi Dave,
i started the setup on an PostgrSQL-free system.
Regards,
Josef Springer
Dave Page wrote:
>
>
>
> ------------------------------------------------------------------------
> 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.
>
| |
| Peter Eisentraut 2005-11-04, 7:23 am |
| 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/
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
| |
| Dave Page 2005-11-04, 7:23 am |
|
> -----Original Message-----
> From: Peter Eisentraut & #91;mailto:peter_e@g
mx.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:
>
> 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/d...y/en-us/odbc/ht
m/ odbcunicode_applicat
ions.asp for example.
Regards, Dave
---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings
| |
| Josef Springer 2005-11-04, 7:23 am |
| 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
Best Regards,
Josef Springer
Dave Page wrote:
>
>
>
> ------------------------------------------------------------------------
> 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.
>
>
> OK, what files are in the installation directory?
>
>
>
> Regards, Dave
>
| |
| Dave Page 2005-11-04, 7:23 am |
|
____________________
____________
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
No, I mean what's in C:\Program Files\psqlODBC (or whereever you
installed it) once installed?
Regards, Dave
| |
| Rainer Bauer 2005-11-04, 9:23 am |
| "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
| |
| Dave Page 2005-11-04, 9:23 am |
|
> -----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:
>
> 2 to 1000,
> of crashes
> successfully ever
>
> 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.
---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings
| |
| Rainer Bauer 2005-11-04, 9:23 am |
| "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_IN
FO == 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_inc
lude_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(s
elf) && ((self->currTuple %
ci->drivers.fetch_max) >= QR_get_num_total_tup
les(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,r
es);
}
+ 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 *****
| |
| Dave Page 2005-11-04, 11:23 am |
|
> -----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:
>
>
> 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
| |
| Rainer Bauer 2005-11-04, 11:23 am |
| "Dave Page" wrote:
>
>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
| |
| Marko Ristola 2005-11-08, 9:24 am |
|
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:
>
>
>
>
>
>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).
>
>
>
>
>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
>
>
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
| |
| Dave Page 2005-11-08, 9:24 am |
|
____________________
____________
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
Please keep discussion on the lists...
If you have a psqlodbclibpq.dll installed, then you are not using the
new version. That file was renamed a while back, before the 2 driver
options were offered. Oh, and the new driver is 08.01.0100, not
08.00.0101 (that's a much older one).
As I asked previously, what files are in C:\Program Files\psqlODBC (or
whereever you installed it)?
Regards, dave.
| |
| Josef Springer 2005-11-09, 3:23 am |
| 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.
>
>
> Err, yes. The Unicode driver is for use with Unicode (UTF-8) data. If
> you want to avoid using Unicode, use the ANSI driver.
>
>
>
> Regards,dave.
>
| |
| Dave Page 2005-11-09, 3:23 am |
| Did the 07 series driver work? The ANSI driver is essentially the same
as the 07 ones.
Regards, Dave
____________________
____________
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.
Err, yes. The Unicode driver is for use with Unicode
(UTF-8) data. If you want to avoid using Unicode, use the ANSI driver.
Regards,dave.
| |
| Dave Page 2005-11-09, 9:23 am |
|
____________________
____________
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 ?
The version 7 driver from www.postgresql.org (yes, it will work with
PostgreSQL 8.x)
Regards,. Dave
| |
| Josef Springer 2005-11-10, 3:23 am |
| 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 !
Regards,
Josef
Dave Page wrote:
>
>
>
> ------------------------------------------------------------------------
> 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 ?
>
>
> The version 7 d river from www.postgresql.org
> <http://www.postgresql.org> (yes, it will work with PostgreSQL 8.x)
>
>
>
> Regards,. Dave
>
| |
| Dave Page 2005-11-10, 7:23 am |
|
____________________
____________
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 !
As far as I'm aware you are the only person seeing such a problem with
the driver - ever since we went back to having two seperate drivers, all
the encoding related complaints vanished overnight.
Perhaps you could expand on the details of your environment a little.
What encoding is used on your clients? What about the server?
Regards, Dave
| |
| Josef Springer 2005-11-14, 7:23 am |
| Hi Dave,
If i run the hole on Windows-XP, all works fine !
On Windows-2000 i have the difficulties only !
Regards,
Josef
Dave Page wrote:
>
>
>
> ------------------------------------------------------------------------
> 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 !
>
>
>
> As far as I'm aware you are the only person seeing such a problem with
> the driver - ever since we went back to having two seperate drivers,
> all the encoding related complaints vanished overnight.
>
>
>
> Perhaps you could expand on the details of your environment a little.
> What encoding is used on your clients? What about the server?
>
>
>
> Regards, Dave
>
| |
| Josef Springer 2005-11-17, 9:23 am |
| Hi Dave,
Database: Windows-XP, encoding: UNICODE, used via ODBC
Client Windows-XP (same client), encoding: UNICODE
Regards,
Josef
Dave Page wrote:
>
> ------------------------------------------------------------------------
> 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 !
>
> As far as I'm aware you are the only person seeing such a problem with
> the driver - ever since we went back to having two seperate drivers,
> all the encoding related complaints vanished overnight.
>
> Perhaps you could expand on the details of yourenvironment a little.
> Whatencoding is used on your clients? What about the server?
>
> Regards, Dave
>
|
|
|
|
|