Details
-
Bug
-
Status: Stalled (View Workflow)
-
Major
-
Resolution: Unresolved
-
10.3(EOL), 10.4(EOL), 10.5
-
None
Description
in the test case from MDEV-18432:
source include/have_binlog_format_row.inc;
|
source include/master-slave.inc;
|
create table t1 (a int, rs timestamp(6) not null, re timestamp(6) not null); |
sync_slave_with_master;
|
stop slave;
|
drop table t1; |
create table t1 (a int, rs timestamp(6) as row start, re timestamp(6) as row end, period for system_time(rs,re)) with system versioning; |
start slave;
|
connection master; |
# create two rows on the slave: one in the past, one with some fake row_start |
insert t1 values (1, '2010-10-10 10:10:10', '2011-11-11 11:11:11'); |
insert t1 values (2, '2012-12-12 12:12:12', from_unixtime(2147483647.999999)); |
sync_slave_with_master;
|
select * from t1; |
select * from t1 for system_time all; |
connection master; |
# now update the versioned row on the slave without leaving any trace |
update t1 set a=3, rs='2009-09-09 9:9:9' where a=2; |
sync_slave_with_master;
|
select * from t1; |
select * from t1 for system_time all; |
connection master; |
drop table t1; |
source include/rpl_end.inc;
|
one can create an arbitrary history on the slave, even if the slave is run with --secure-timestamp=YES. This should not be possible, if secure_timestamp is YES slave should ignore row_start/row_end values coming from the master in row events.
Attachments
Issue Links
- blocks
-
MDEV-18432 RBR logging of system versioned tables
- Stalled