The non-persistent UPDATE_TIME for InnoDB tables is not being updated consistently at transaction commit.

If a transaction is partly rolled back so that in the end it will not modify a table that it intended to modify, the update_time will be updated nevertheless. This will also happen when InnoDB fails to write an undo log record for the intended modification.

If a transaction is committed internally in InnoDB, instead of being committed from the SQL interface, then the trx_t::mod_tables will not be applied to the update_time of the tables.

The problem can be demonstrated with the following:

diff --git a/mysql-test/suite/innodb/t/update_time_wl6658.test b/mysql-test/suite/innodb/t/update_time_wl6658.test

index 0b2b94ae2a9..d7ecfc4961f 100644

--- a/mysql-test/suite/innodb/t/update_time_wl6658.test

+++ b/mysql-test/suite/innodb/t/update_time_wl6658.test

@@ -187,8 +187,9 @@ SELECT update_time

 FROM information_schema.tables WHERE table_name='tab1i';

 BEGIN WORK;

-INSERT INTO tab2 VALUES(1,'Oracle','NUTT',10);

+DELETE FROM tab1i;

 SAVEPOINT A;

+INSERT INTO tab2 VALUES(1,'Oracle','NUTT',10);

 INSERT INTO tab2 VALUES(2,'HUAWEI','BOLT',40);

 SAVEPOINT B;

 INSERT INTO tab2 VALUES(3,'IBM','NAIL',70);

With this change to the test, the end effect of the transaction (which will do ROLLBACK TO A before COMMIT) is that it will not modify tab2. Yet, the UPDATE_TIME of tab2 is affected.
If the SAVEPOINT A were at the very beginning of the transaction, then it would work correctly; a full ROLLBACK will empty the trx_t::mod_tables.