Hi,
(2012/08/31 20:21), Boszormenyi Zoltan wrote:
> Hi,
>
> we had to recently test psqlODBC with an older application
> which doesn't expect ODBC 3.x.
>
> The problem is that the client locks up as soon as it encounters
> an error of any kind, like restarting the server from under the client
> or simply executing a bad query.
>
> After debugging the problem and reading the code of both
> unixODBC 2.3.1 and psqlODBC (version 09.00.0310 and 09.01.0200),
> I discovered that the DriverManager calls the driver's SQLError()
> and SQLGetDiagRec() in a loop
Does the DriverManager call both SQLError() and SQLGetDiagRec()?
Could you send me (loop part of) the Mylog output?
regards,
Hiroshi Inoue
> and expects it to return the error
> message in pieces and when there is nothing left to return,
> these driver methods must return some SQL error instead of
> SQL_SUCCESS[_WITH_INFO]. SQLGetDiagRec() does this properly
> because the DriverManager keeps track of the pieces via the
> RecNumber argument but SQLError() calls PGAPI_StmtError()
> with RecNumber == -1 every time. Instead, it uses the internal
> error structure to keep track of the string left to return. SQLError()
> calls PGAPI_StmtError() with
> flag = PODBC_ALLOW_PARTIAL_EXTRACT | PODBC_ERROR_CLEAR
> which means that ER_ReturnError() may free the error structure.
>
> The interaction between the looping and the freeing of the error
> structure is buggy, the error makes it go into an infinite loop.
>
> The attached patch fixes this problem. Though, I am not sure about
> whether the (stapos > msglen) and (error->errorpos >= msglen)
> checks are redundant or not.
>
> Best regards,
> Zoltán Böszörményi
