Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
N/A
-
None
Description
Monty was going to fix it anyway, but since it hasn't happened yet, I'll file it so it's not forgotten. I don't think it is an absolute show-stopper for RC, but it must be fixed before GA (of whatever version the feature goes into).
Upon RBR from an old master to a server with 32-bit timestamp ROW END values of system-versioned tables are written in the binary log explicitly and are replicated "as is" (2038-...), so they become historical rows on the new server. It is true both for tables with automatic ROW START/END fields and for custom ones, when versioning is timestamp-based.
On an old master:
set binlog_format=row; |
create or replace table t (a int primary key) with system versioning; |
insert into t values (1); |
The binary log:
|
11.3 83a79ba33b0d39f005deeb3b2392cf85b7cf0fc5 |
#Q> insert into t values (1)
|
#240201 21:12:14 server id 1 end_log_pos 1893 CRC32 0xdcd4a075 Table_map: `test`.`t` mapped to number 23
|
# at 1893
|
#240201 21:12:14 server id 1 end_log_pos 1945 CRC32 0x440f3b5c Write_rows: table id 23 flags: STMT_END_F
|
### INSERT INTO `test`.`t`
|
### SET
|
### @1=1
|
### @2=1706814734.366689
|
### @3=2147483647.999999
|
# Number of rows: 1
|
# at 1945
|
On the new server:
|
bb-11.4-timestamp 1ab5dabd3aa0e11e35362552a7bcb2241f570e76 |
MariaDB [test]> select *, row_start, row_end from t for system_time all; |
+---+----------------------------+----------------------------+ |
| a | row_start | row_end |
|
+---+----------------------------+----------------------------+ |
| 1 | 2024-02-01 21:12:14.366689 | 2038-01-19 05:14:07.999999 |
|
+---+----------------------------+----------------------------+ |
1 row in set (0.002 sec) |
 |
MariaDB [test]> select * from t ; |
Empty set (0.001 sec) |
Attachments
Issue Links
- is caused by
-
MDEV-32188 make TIMESTAMP use whole 32-bit unsigned range
-
- Closed
-