mirror of
https://github.com/MariaDB/server.git
synced 2025-02-07 06:12:18 +01:00
dfdedd46e4
This patch extends the timestamp from 2038-01-19 03:14:07.999999 to 2106-02-07 06:28:15.999999 for 64 bit hardware and OS where 'long' is 64 bits. This is true for 64 bit Linux but not for Windows. This is done by treating the 32 bit stored int as unsigned instead of signed. This is safe as MariaDB has never accepted dates before the epoch (1970). The benefit of this approach that for normal timestamp the storage is compatible with earlier version. However for tables using system versioning we before stored a timestamp with the year 2038 as the 'max timestamp', which is used to detect current values. This patch stores the new 2106 year max value as the max timestamp. This means that old tables using system versioning needs to be updated with mariadb-upgrade when moving them to 11.4. That will be done in a separate commit.
56 lines
2 KiB
Text
56 lines
2 KiB
Text
--source suite/versioning/sys_time.inc
|
|
|
|
#
|
|
# simple tests that don't need to be run in multiple various combinations
|
|
#
|
|
set time_zone='+00:00';
|
|
|
|
|
|
--echo #
|
|
--echo # MDEV-29750 triggers can modify history
|
|
--echo #
|
|
set sql_mode='', timestamp=unix_timestamp('2010-10-10 10:10:10');
|
|
create table t (a int, b int as (a+1), s timestamp(6) as row start, e timestamp(6) as row end, period for system_time(s,e)) with system versioning;
|
|
insert into t values (1,1, '2022-01-01','2023-01-01'),(2,2, '2022-02-02','2023-02-02');
|
|
create trigger tr before insert on t for each row set new.b=1, new.s = '2022-03-03', new.e = '2023-03-03';
|
|
insert into t (a) values (3),(4);
|
|
--replace_result $sys_time_max_replace SYS_TIME_MAX
|
|
select * from t for system_time all;
|
|
drop table t;
|
|
set sql_mode=default, timestamp=default;
|
|
|
|
--echo #
|
|
--echo # End of 10.3 tests
|
|
--echo #
|
|
#
|
|
# simple tests that don't need to be run in multiple various combinations
|
|
#
|
|
set time_zone='+00:00';
|
|
|
|
--echo #
|
|
--echo # MDEV-29721 Inconsistency upon inserting history with visible system versioning columns
|
|
--echo #
|
|
create table t1 (a int, s timestamp(6) as row start, e timestamp(6) as row end, period for system_time(s,e)) with system versioning;
|
|
set system_versioning_insert_history=on;
|
|
set timestamp=unix_timestamp('2010-10-10 10:10:10');
|
|
insert t1 (a,s,e) values (1,'2020-01-01',default), (2,'2020-02-02',ignore),(3,default,'2020-03-03'), (4,ignore,'2020-04-04');
|
|
set timestamp=unix_timestamp('2010-11-11 11:11:11');
|
|
insert t1 values (5,'2020-01-01',default), (6,'2020-02-02',ignore),(7,default,'2020-03-03'), (8,ignore,'2020-04-04');
|
|
set timestamp=default;
|
|
--replace_result $sys_time_max_replace SYS_TIME_MAX
|
|
select * from t1 for system_time all;
|
|
drop table t1;
|
|
|
|
--echo #
|
|
--echo # MDEV-29830 Assertion `table->versioned()' in THD::vers_insert_history_fast
|
|
--echo #
|
|
create table t1 (a int) with system versioning;
|
|
insert into t1 values (1),(2);
|
|
create table t2 (a timestamp);
|
|
insert into t2 (a) values (now()),(now());
|
|
select * from t2 where a in (select row_start from t1);
|
|
drop table t1, t2;
|
|
|
|
--echo #
|
|
--echo # End of 10.11 tests
|
|
--echo #
|