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

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.



Re: UseDeclareFetch=1, Fetch=100, UseServerSidePrepare=0

By Hiroshi Inoue at 04/22/2013 - 19:47

Hi Jack,

(2013/04/22 2:56), ljwilson wrote:
Could you please upload it somewhere?

Hiroshi Inoue

Re: UseDeclareFetch=1, Fetch=100, UseServerSidePrepare=0

By Heikki Linnakangas at 04/22/2013 - 02:40

On 21.04.2013 20:56, ljwilson wrote:
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

Re: UseDeclareFetch=1, Fetch=100, UseServerSidePrepare=0

By Jack Wilson at 04/22/2013 - 16:15

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

Last "good" commit:
<a href=";a=commit;h=3cf4dedfbb435f653785a967e951956046f0a8cb" title=";a=commit;h=3cf4dedfbb435f653785a967e951956046f0a8cb">;a=commit;h=3cf4dedfbb43...</a>

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:
<a href=";a=commit;h=6e45dcb08093d81f244ad6321cbd529d0a7efe61" title=";a=commit;h=6e45dcb08093d81f244ad6321cbd529d0a7efe61">;a=commit;h=6e45dcb08093...</a>

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.