Bug #7990 | mysql_stmt_close doesn't reset mysql->net.last_error | ||
---|---|---|---|
Submitted: | 18 Jan 2005 16:31 | Modified: | 10 Feb 2005 17:08 |
Reporter: | Georg Richter | Email Updates: | |
Status: | Closed | Impact on me: | |
Category: | MySQL Server | Severity: | S3 (Non-critical) |
Version: | 4.1.9 + 5.0.3 | OS: | Linux (Linux SLES 8) |
Assigned to: | Konstantin Osipov | CPU Architecture: | Any |
[18 Jan 2005 16:31]
Georg Richter
[18 Jan 2005 22:50]
MySQL Verification Team
Thank you for the bug report.
[24 Jan 2005 0:09]
Konstantin Osipov
Georg, I believe mysql_stmt_close() shouldn't reset mysql->net.last_error. This way we can mistakenly reset an error from another statement. I think that instead we should clear net.last_error whenever we copy it to stmt. Since mysql_stmt_init was introduced, you always can fetch error of prepare from statement handle itself. Do you agree with the above?
[24 Jan 2005 6:12]
Georg Richter
Konstantin: Clearing net.last_error when copying to stmt handle makes much more sense - however I'm not sure if this will break BC.
[10 Feb 2005 14:06]
Konstantin Osipov
Subject: bk commit - 4.1 tree (konstantin:1.2168) BUG#7990 ChangeSet 1.2168 05/02/10 17:01:41 konstantin@mysql.com +2 -0 A fix and test case for Bug#7990 "mysql_stmt_close doesn't reset mysql->net.last_error": the solution is to clear MYSQL->net error before performing COM_CLOSE: if the call succeeds, the connection is usable for other statements. More comprehensive fix is to clear MYSQL->net for all recoverable errors at the time they happen, it will be implemented in 5.0 as it introduces incompatibility in behavior.
[10 Feb 2005 14:54]
Konstantin Osipov
Pushed into 4.1 tree which is currently tagged 4.1.10
[10 Feb 2005 17:08]
Paul DuBois
Mentioned in 4.1.10 change notes.