| Bug #22913 | mysql --quick doesn't report some errors | ||
|---|---|---|---|
| Submitted: | 3 Oct 2006 0:04 | Modified: | 14 Nov 2006 3:30 |
| Reporter: | Morgan Tocker | Email Updates: | |
| Status: | Closed | Impact on me: | |
| Category: | MySQL Server: Command-line Clients | Severity: | S3 (Non-critical) |
| Version: | 4.0, 4.1, 5.0 | OS: | |
| Assigned to: | Ramil Kalimullin | CPU Architecture: | Any |
[3 Oct 2006 0:08]
Morgan Tocker
Suggested fix was truncated....
In client/mysqlcc:7070 (5.1 tree):
if (quick)
{
if (!(result=mysql_use_result(&mysql)) && mysql_field_count(&mysql))
{
executing_query= 0;
return put_error(&mysql);
}
}
else
{
error= mysql_store_result_for_lazy(&result);
if (error)
{
executing_query= 0;
return error;
}
}
mysql_use_result shouldn't return an error. The problem is that print_table_data does not check mysql_errno when the mysql_fetch_row loop completes and the caller to print_table_data also does not check.
[3 Oct 2006 9:19]
Valeriy Kravchuk
Thank you for a bug report.
[3 Oct 2006 18:02]
Dean Ellis
None of the print_table_data functions check for errors during their mysql_fetch_row() loops, so errors that occur after mysql_use_result() will be silently dropped.
Something like this might help:
===== mysql.cc 1.231 vs edited =====
--- 1.231/client/mysql.cc 2006-10-03 13:09:27 -05:00
+++ edited/mysql.cc 2006-10-03 13:07:55 -05:00
@@ -2087,6 +2087,7 @@
(long) mysql_num_rows(result),
(long) mysql_num_rows(result) == 1 ? "row" : "rows");
end_pager();
+ if (mysql_errno(&mysql)) error= put_error(&mysql);
}
}
else if (mysql_affected_rows(&mysql) == ~(ulonglong) 0)
[6 Oct 2006 10:36]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/13236 ChangeSet@1.2543, 2006-10-06 15:35:08+05:00, ramil@mysql.com +1 -0 Fix for bug #22913: mysql --quick doesn't report some errors. We don't check for errors that may occure diring data printing.
[12 Oct 2006 8:20]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/13558 ChangeSet@1.2543, 2006-10-12 13:19:38+05:00, ramil@mysql.com +1 -0 Fix for bug #22913: mysql --quick doesn't report some errors. We don't check for errors that may occur diring data printing.
[2 Nov 2006 10:30]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/14728 ChangeSet@1.2543, 2006-11-02 14:32:00+04:00, ramil@mysql.com +1 -0 Fix for bug #22913: mysql --quick doesn't report some errors. We don't check for errors that may occur during data printing.
[14 Nov 2006 3:30]
Paul DuBois
Noted in 4.1.23, 5.0.30 (not 5.0.29), 5.1.13 changelogs. mysql did not check for errors when fetching data during result set printing.
Description: With mysql --quick, there is no error checking while fetching rows. You can test this by breaking on the fetch and then killing the server. The result is that the he client stops but does not print any error messages and appears to have completed the query. Verified in 4.0.26, 4.1.21 and 5.0.24a. How to repeat: An example when using a custom table handler, is that the header output is returned, but no data for rows: $ mysql -q -uroot -pPASSWORD -hHOSTNAME DATABASE -e 'select count(*) from tbl' +-----------------------+ | count(*) | +-----------------------+ +-----------------------+ Suggested fix: In client/mysqlcc:7070 (5.1 tree): if (quick) { if (!(result=mysql_use_result(&mysql)) && mysql_field_count(&mysql)) { executing_query= 0; return put_error(&mysq