Details
-
Bug
-
Status: Closed (View Workflow)
-
Critical
-
Resolution: Fixed
-
10.2(EOL), 10.3(EOL), 10.4(EOL), 10.5, 10.6, 10.7(EOL), 10.8(EOL), 10.9(EOL), 10.10(EOL)
-
None
Description
--source include/have_binlog_format_row.inc
|
|
|
SET binlog_row_image= MINIMAL; |
|
|
CREATE TABLE t1 (a INT NOT NULL DEFAULT 0 PRIMARY KEY); |
REPLACE INTO t1 () VALUES (),(); |
|
|
# Cleanup
|
DROP TABLE t1; |
|
10.2 3c021485 |
mysqltest: At line 6: query 'REPLACE INTO t1 () VALUES (),()' failed: 1534: Writing one row to the row-based binary log failed |
Reproducible on 10.1-10.6, MySQL 5.6-8.0.
Attachments
Activity
Nice find btw, elenst! It is quite bad that a simple REPLACE statement fails to binlog outright like this, though it is of course a rather special corner case which makes it less of a problem in practice probably.
The direct cause of this is that the particular REPLACE INTO () VALUES (), () causes a special case where a write rows event is binlogged with a zero-length after-image. At some point in the history, the code was changed so that m_rows_buf is not allocated when not needed, but is_valid() was not updated to reflect this, so is_valid() incorrectly returns false for this write rows event. And this causes the failure when the second () is binlogged as an update rows event which ends up checking is_valid() for the prior write rows event.
So this looks like a regression, though I did not spend the effort to research the commit history to discover exactly which version it was introduced in. There are a number of other places in the code where it explicitly handles the case that the after image can be empty like this.
Pushed to 10.5