Обсуждение: UseDeclareFetch=1, Fetch=100, UseServerSidePrepare=0 causes Windows gpf in Unicode Driver versions > 08.04.0200
I've been upgrading some Windows servers from PostgreSQL 8.3.18 to 9.2.4. Along with that I upgraded psqlODBC for the Windows clients from 8.0x.xxxx to 09.01.0200. All was fine until I had a customer who could consistently get a gpf in psqlodbc35w.dll when doing an export. Getting a copy of their database, I could reproduce as well. Trying different driver versions, I've found no crashes with the 8.0x psqlODBC series, but I can reproduce the gpf starting with 09.00.xxxx through the latest 9.01.02?? that I compiled yesterday (2013/04/20) from the git repository. I've used UseDeclareFetch=1 and Fetch=100 since I started with PostgreSQL back in 2008. Now with the 09.xx.xxxx drivers I don't get a crash if I: 1. Set UseDeclareFetch=0 or 2. Set UseServerSidePrepare=1 I've got a 31MB mylog file (zipped) of an entire client session. I can uploaded somewhere if that would help The bulk of that could be stripped-out; probably just the first and last 1000 lines are relevant. The actual sql is doing an update one record at a time of a numeric(14,0) value. It updates the first two records, executes a fetch, then crashes (when UseDeclareFetch=1 and UseServerSidePrepare=0). These are the last lines in mylog before the gpf occurs: [14028-1870.117][SQLExtendedFetch][14028-1870.117]PGAPI_ExtendedFetch: stmt=03988330 rowsetSize=20 [14028-1870.117]SQL_FETCH_NEXT: num_tuples=500, currtuple=460, rowst=460 [14028-1870.118]PGAPI_ExtendedFetch: new currTuple = 479 [14028-1870.118]fetch_cursor=1, 054FEF28->total_read=500 [14028-1870.118]**** SC_fetch: non-cursor_result [14028-1870.118]fetch: cols=42, lf=0, opts = 039883B8, opts->bindings = 03A36758, buffer[] = 03C607C8 [14028-1870.119]type = 23, atttypmod = -1 Obviously I can start using UseServerSidePrepare=1, but I'm concerned that would be masking a bug that should be addressed. Thanks...jack -- View this message in context: http://postgresql.1045698.n5.nabble.com/UseDeclareFetch-1-Fetch-100-UseServerSidePrepare-0-causes-Windows-gpf-in-Unicode-Driver-versions-08-0-tp5752790.html Sent from the PostgreSQL - odbc mailing list archive at Nabble.com.
On 21.04.2013 20:56, ljwilson wrote: > I've been upgrading some Windows servers from PostgreSQL 8.3.18 to 9.2.4. > Along with that I upgraded psqlODBC for the Windows clients from 8.0x.xxxx > to 09.01.0200. > > All was fine until I had a customer who could consistently get a gpf in > psqlodbc35w.dll when doing an export. > > Getting a copy of their database, I could reproduce as well. > > Trying different driver versions, I've found no crashes with the 8.0x > psqlODBC series, but I can reproduce the gpf starting with 09.00.xxxx > through the latest 9.01.02?? that I compiled yesterday (2013/04/20) from the > git repository. > > I've used UseDeclareFetch=1 and Fetch=100 since I started with PostgreSQL > back in 2008. > > Now with the 09.xx.xxxx drivers I don't get a crash if I: > > 1. Set UseDeclareFetch=0 > or > 2. Set UseServerSidePrepare=1 > > I've got a 31MB mylog file (zipped) of an entire client session. I can > uploaded somewhere if that would help The bulk of that could be > stripped-out; probably just the first and last 1000 lines are relevant. The > actual sql is doing an update one record at a time of a numeric(14,0) value. > It updates the first two records, executes a fetch, then crashes (when > UseDeclareFetch=1 and UseServerSidePrepare=0). If you could reduce it to a small self-contained test program, that would help a lot. Or if you could narrow it down to the commit that introduced the problem, using "git bisect". - Heikki
Using git bisect, where "good" is defined as not crashing the PostgreSQL server nor causing a gpf in the client program, and "bad" does one or the other): Last "good" commit: http://git.postgresql.org/gitweb/?p=psqlodbc.git;a=commit;h=3cf4dedfbb435f653785a967e951956046f0a8cb <http://git.postgresql.org/gitweb/?p=psqlodbc.git;a=commit;h=3cf4dedfbb435f653785a967e951956046f0a8cb> The commit right after that actually crashes the PostgreSQL 9.2.4 server--I don't get a chance to get a gpf at the client when running my test: (this is in the server log) 2013-04-22 15:47:04 EDT LOG server process (PID 13732) was terminated by exception 0xC0000005 First "bad" commit: http://git.postgresql.org/gitweb/?p=psqlodbc.git;a=commit;h=6e45dcb08093d81f244ad6321cbd529d0a7efe61 <http://git.postgresql.org/gitweb/?p=psqlodbc.git;a=commit;h=6e45dcb08093d81f244ad6321cbd529d0a7efe61> Note that this "bad" commit requires 09.00 headers to compile (though version is still at 08.04), otherwise get two unresolved externals: loadlib.obj : error LNK2019: unresolved external symbol _PQescapeLiteral referenced in function _connect_with_param_available loadlib.obj : error LNK2019: unresolved external symbol _PQconnectdbParams referenced in function _CALL_PQconnectdbParams .\Release\psqlodbc35w.dll : fatal error LNK1120: 2 unresolved externals Apparently those two symbols were introduced in the 09.00 code stream. Thanks...jack -- View this message in context: http://postgresql.1045698.n5.nabble.com/UseDeclareFetch-1-Fetch-100-UseServerSidePrepare-0-causes-Windows-gpf-in-Unicode-Driver-versions-08-0-tp5752790p5752937.html Sent from the PostgreSQL - odbc mailing list archive at Nabble.com.
Hi Jack, (2013/04/22 2:56), ljwilson wrote: > I've been upgrading some Windows servers from PostgreSQL 8.3.18 to 9.2.4. > Along with that I upgraded psqlODBC for the Windows clients from 8.0x.xxxx > to 09.01.0200. > > All was fine until I had a customer who could consistently get a gpf in > psqlodbc35w.dll when doing an export. > > Getting a copy of their database, I could reproduce as well. > > Trying different driver versions, I've found no crashes with the 8.0x > psqlODBC series, but I can reproduce the gpf starting with 09.00.xxxx > through the latest 9.01.02?? that I compiled yesterday (2013/04/20) from the > git repository. > > I've used UseDeclareFetch=1 and Fetch=100 since I started with PostgreSQL > back in 2008. > > Now with the 09.xx.xxxx drivers I don't get a crash if I: > > 1. Set UseDeclareFetch=0 > or > 2. Set UseServerSidePrepare=1 > > I've got a 31MB mylog file (zipped) of an entire client session. I can > uploaded somewhere if that would help Could you please upload it somewhere? regards, Hiroshi Inoue