Re: UseDeclareFetch=1, Fetch=100, UseServerSidePrepare=0 causes Windows gpf in Unicode Driver versions > 08.04.0200
От | Heikki Linnakangas |
---|---|
Тема | Re: UseDeclareFetch=1, Fetch=100, UseServerSidePrepare=0 causes Windows gpf in Unicode Driver versions > 08.04.0200 |
Дата | |
Msg-id | 5174DB4D.4060405@vmware.com обсуждение исходный текст |
Ответ на | UseDeclareFetch=1, Fetch=100, UseServerSidePrepare=0 causes Windows gpf in Unicode Driver versions > 08.04.0200 (ljwilson <ljwilson@digitalav.com>) |
Ответы |
Re: UseDeclareFetch=1, Fetch=100, UseServerSidePrepare=0 causes
Windows gpf in Unicode Driver versions > 08.04.0200
|
Список | pgsql-odbc |
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
В списке pgsql-odbc по дате отправления: