Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
11.8.9
-
Can result in unexpected behaviour
-
Better handled i/o errors in DELETE
Description
DELETE skips the row without reporting anything when error is returned by handler::ha_rnd_pos()
// sql/sql_delete.cc, multi_delete::rowid_table_deletes()
|
DBUG_ASSERT(!tmp_table->field[0]->is_null());
|
String rowid;
|
tmp_table->field[0]->val_str(&rowid);
|
if (unlikely((local_error= table->file->ha_rnd_pos(table->record[0], |
(uchar*)rowid.ptr()))))
|
{
|
// Table aliased to itself had key deleted already |
continue; |
}
|
If the engine also requested a full rollback (i.e. it called
thd_mark_transaction_to_rollback(thd, all=true) before returning the
error, then application sees "Query OK, N rows affected".
It is a regression.* Before MDEV-30469 this loop was driven by
Suggested fix
Report every error except the two that genuinely mean "the row is not there
any more"
--- a/sql/sql_delete.cc
|
+++ b/sql/sql_delete.cc
|
@@ multi_delete::rowid_table_deletes()
|
if (unlikely((local_error= table->file->ha_rnd_pos(table->record[0],
|
(uchar*)rowid.ptr()))))
|
{
|
- // Table aliased to itself had key deleted already
|
- continue;
|
+ if (local_error != HA_ERR_KEY_NOT_FOUND &&
|
+ local_error != HA_ERR_END_OF_FILE)
|
+ {
|
+ err_table= table;
|
+ goto err;
|
+ }
|
+ local_error= 0;
|
+ continue;
|
} |
Attachments
Issue Links
- relates to
-
-
- Open
-
