Details
-
Bug
-
Status: Open (View Workflow)
-
Major
-
Resolution: Unresolved
-
10.6, 10.11, 11.4, 11.8, 12.3, 13.0
-
Can result in unexpected behaviour
Description
The failure is non-deterministic, run with --repeat=N. There is no concurrency here, but apparently ALTER .. ORDER BY is non-deterministic, and the failure occurs when the tables end up with a different row order on master and slave, or something like that.
It usually fails for me within several attempts, but it can vary on different machines and builds. Specifically, use a non-ASAN build to reproduce. At the time of filing, it was failing for me on all of my release and debug builds, but never on any ASAN build.
--source include/have_binlog_format_row.inc
|
--source include/master-slave.inc
|
 |
CREATE TABLE t (f1 VARCHAR(1), f2 INT, f3 VARCHAR(8), UNIQUE(f1)) ENGINE=HEAP; |
INSERT INTO t VALUES ('a', 1, 'foo'), ('b', 1, 'bar'); |
ALTER TABLE t ORDER BY f2; |
ALTER TABLE t ADD pk INT AUTO_INCREMENT PRIMARY KEY; |
UPDATE t SET f2 = 0; |
--sync_slave_with_master
|
--connection master
|
DROP TABLE t; |
--source include/rpl_end.inc |
|
10.11 d3afdd162bf8aecde785ccff0fd3dbe47e14923f |
Last_SQL_Error Could not execute Update_rows_v1 event on table test.t; Duplicate entry 'b' for key 'f1', Error_code: 1062; handler error HA_ERR_FOUND_DUPP_KEY; the event's master log master-bin.000001, end_log_pos 1361 |
Attachments
Issue Links
- relates to
-
MDEV-39335 Do not replicate memory tables by default
-
- Open
-
