Details
-
Bug
-
Status: Closed (View Workflow)
-
Critical
-
Resolution: Fixed
-
10.5, 10.6, 10.7(EOL), 10.8(EOL), 10.9(EOL), 10.10(EOL)
Description
mleich produced rr record traces where a child page number in a B-tree record was recovered incorrectly. The culprit seems to be an overzealous optimization:
diff --git a/storage/innobase/page/page0cur.cc b/storage/innobase/page/page0cur.cc
|
index dc740cad862..d37d3d85f96 100644
|
--- a/storage/innobase/page/page0cur.cc
|
+++ b/storage/innobase/page/page0cur.cc
|
@@ -1579,8 +1579,12 @@ page_cur_insert_rec_low(
|
const byte *r= rec;
|
const byte *c= cur->rec;
|
const byte *c_end= cur->rec + data_size;
|
+ static_assert(REC_N_OLD_EXTRA_BYTES == REC_N_NEW_EXTRA_BYTES + 1, "");
|
if (c <= insert_buf && c_end > insert_buf)
|
c_end= insert_buf;
|
+ else if (c_end < next_rec &&
|
+ c_end >= next_rec - REC_N_OLD_EXTRA_BYTES + comp)
|
+ c_end= next_rec - REC_N_OLD_EXTRA_BYTES + comp;
|
else
|
c_end= std::min<const byte*>(c_end, block->page.frame + srv_page_size -
|
PAGE_DIR - PAGE_DIR_SLOT_SIZE * |
That is, we would compare the bytes of the being-inserted record to some header bytes of next_rec that were just updated by the same function, without them being written to the redo log at all.
Attachments
Issue Links
- is caused by
-
MDEV-21724 Optimize page_cur_insert_rec_low() redo logging
- Closed
- relates to
-
MDEV-29438 Recovery or backup of instant ALTER TABLE is incorrect
- Closed
-
MDEV-28312 [FATAL] InnoDB: Page old data size XXX new data size XXX, page old max ins size XXX new max ins size XXX
- Closed