Sergei Petrunia added a comment - 2019-09-06 09:02 An observation by marko : in InnoDB, the Update_time is non-persistent, the data is only stored in InnoDB's in-memory structure. (This is important, as maintaining a fast-changing value on disk would cause IO overhead or require some clever tricks). Check_time is always NULL for InnoDB tables.

Sergei Petrunia added a comment - 2019-09-06 09:05 Checked if upstream FB/MySQL 5.6 have implemented this feature - no, they don't have it.

Sergei Petrunia added a comment - 2019-09-06 20:27 The patch was pushed to https://github.com/MariaDB/server/tree/bb-10.4-mdev17171 , waiting for BB pass for it.

Sergei Petrunia added a comment - 2019-09-07 07:46 Pull request against FB/MySQL-5.6 upstream : https://github.com/facebook/mysql-5.6/pull/1046

Sergei Petrunia added a comment - 2019-09-18 14:09 - edited Got a question, what is/should happen with create_time when somebody runs ALTER TABLE ? Trying it on InnoDB mysql> create table t1 (pk int, a int, b int, c int) engine=innodb; Query OK, 0 rows affected (0.03 sec)   mysql> insert into t1 (pk) values (1); Query OK, 1 row affected (0.00 sec)   mysql> select create_time, update_time, check_time from information_schema.tables where table_schema=database() and table_name='t1'; +---------------------+---------------------+------------+ | create_time | update_time | check_time | +---------------------+---------------------+------------+ | 2019-09-18 17:03:16 | 2019-09-18 17:03:27 | NULL | +---------------------+---------------------+------------+ 1 row in set (0.00 sec) mysql> alter table t1 add key(a); Query OK, 0 rows affected (0.02 sec) Records: 0 Duplicates: 0 Warnings: 0   mysql> select create_time, update_time, check_time from information_schema.tables where table_schema=database() and table_name='t1'; +---------------------+---------------------+------------+ | create_time | update_time | check_time | +---------------------+---------------------+------------+ | 2019-09-18 17:03:55 | 2019-09-18 17:03:27 | NULL | +---------------------+---------------------+------------+ 1 row in set (0.00 sec) mysql> select now(); +---------------------+ | now() | +---------------------+ | 2019-09-18 17:04:12 | +---------------------+ 1 row in set (0.00 sec)   mysql> alter table t1 drop key a; Query OK, 0 rows affected (0.02 sec) Records: 0 Duplicates: 0 Warnings: 0   mysql> select create_time, update_time, check_time from information_schema.tables where table_schema=database() and table_name='t1'; +---------------------+---------------------+------------+ | create_time | update_time | check_time | +---------------------+---------------------+------------+ | 2019-09-18 17:04:17 | 2019-09-18 17:03:27 | NULL | +---------------------+---------------------+------------+ 1 row in set (0.01 sec) So, for in-place ALTER TABLE: create_time is updated update_time does not change mysql> alter table t1 add primary key (pk); Query OK, 0 rows affected (0.03 sec) Records: 0 Duplicates: 0 Warnings: 0 mysql> select create_time, update_time, check_time from information_schema.tables where table_schema=database() and table_name='t1'; +---------------------+-------------+------------+ | create_time | update_time | check_time | +---------------------+-------------+------------+ | 2019-09-18 17:10:17 | NULL | NULL | +---------------------+-------------+------------+ if ALTER TABLE requires table rebuild: create_time is updated update_time is set to NULL

Sergei Petrunia added a comment - 2019-09-24 11:28 Addressed review input. Got another kind of input: the updated patch makes the data dictionary backward-incompatible (the new server can read the old datadir; old server will not start on the new datadir). This is not a good thing. Together with Yoshinori, designed a way to change the data dictionary format so that it is backward and forward- compatible.

Sergei Petrunia added a comment - 2019-10-15 16:44 Setting to Blocker as discussed with serg .