Details
-
Bug
-
Status: Closed (View Workflow)
-
Blocker
-
Resolution: Won't Fix
-
N/A
-
None
Description
The recent MySQL 5.7.43 release includes only one change to the InnoDB storage engine:
Not applicable to MariaDB Server
Bug#34741689: mysqld crash at row_upd_sec_index_entry_low
This bug had been fixed in MDEV-15114. The logic around virtual columns was improved further in MDEV-18366. I tested both the fix of MDEV-18366 and its parent commit using the test case and the following patch, to avoid an assertion failure during the execution of the DELETE statement:
diff --git a/sql/field.cc b/sql/field.cc
|
index bdaaecc2026..cd06777313e 100644
|
--- a/sql/field.cc
|
+++ b/sql/field.cc
|
@@ -8340,7 +8340,6 @@ int Field_blob::store(longlong nr, bool unsigned_val)
|
|
double Field_blob::val_real(void)
|
{
|
- ASSERT_COLUMN_MARKED_FOR_READ;
|
char *blob;
|
memcpy(&blob, ptr+packlength, sizeof(char*));
|
if (!blob) |
Whatever caused this debug assertion to fail has been fixed since the time of the MDEV-18366 fix.
In neither case (testing with or without the fix of MDEV-18366) did the UPDATE statement invoke innobase_get_computed_value(). That is, the value of the indexed virtual column was computed only once, in the SQL layer. In MySQL 5.7.43, the UPDATE statement will compute the values of indexed virtual columns twice, and it will also copy some memory to avoid trashing buffers during the redundant computation.
Attachments
Issue Links
- blocks
-
MDEV-32579 Merge new release of InnoDB 5.7.44 to 10.4
- Closed
- is blocked by
-
MDEV-15114 ASAN heap-use-after-free in mem_heap_dup or dfield_data_is_binary_equal
- Closed
-
MDEV-31087 Merge new release of InnoDB 5.7.42 to 10.3
- Closed