Details
-
Bug
-
Status: Closed (View Workflow)
-
Critical
-
Resolution: Fixed
-
N/A
-
None
Description
Filing as 10.11v1- critical as previously discussed, to make it show up on the list for consideration. Please feel free to downgrade or close as "won't fix".
To insert into history columns, both values have to be specified, even though period columns have natural defaults which are used for "normal" DML.
create or replace table t (a int) with system versioning; |
set system_versioning_insert_history=on; |
insert into t (a) values (1); |
insert into t (a, row_start, row_end) values (2,NOW(6),from_unixtime(2147483647.999999)); |
insert into t (a, row_start) values (3,NOW(6)); |
insert into t (a, row_end) values (4,from_unixtime(2147483647.999999)); |
 |
# Cleanup
|
drop table t; |
First two INSERTs work the same way, using the current time for row start and the max timestamp for row end.
The other two INSERTs fail. Instead of using the current time and the max timestamp, they appear to be using by default zero time values.
bb-10.11-MDEV-16546 2b1d32429 |
insert into t (a, row_start) values (3,NOW(6)); |
mysqltest: At line 5: query 'insert into t (a, row_start) values (3,NOW(6))' failed: ER_WRONG_VALUE (1525): Incorrect row_start value: '2022-10-06 15:01:00.525481' |
insert into t (a, row_end) values (4,from_unixtime(2147483647.999999)); |
mysqltest: At line 6: query 'insert into t (a, row_end) values (4,from_unixtime(2147483647.999999))' failed: ER_WRONG_VALUE (1525): Incorrect row_start value: '0000-00-00 00:00:00.000000' |
Attachments
Issue Links
- is caused by
-
MDEV-16546 System versioning setting to allow history modification
- Closed
- is part of
-
MDEV-29721 Inconsistency upon inserting history with visible system versioning columns
- Closed