[MDEV-21287] AFTER UPDATE trigger and ON UPDATE now(): new value <> persisted value Created: 2019-12-11  Updated: 2023-04-27

Status: Open
Project: MariaDB Server
Component/s: Triggers
Affects Version/s: 10.3.18, 10.3.20, 10.3.21, 10.4.10, 10.4.11, 10.5.5
Fix Version/s: 10.4

Type: Bug Priority: Major
Reporter: Pierre-Jean Clement Assignee: Oleksandr Byelkin
Resolution: Unresolved Votes: 0
Labels: None
Environment:

Linux/Debian Buster 10.2


Issue Links:
Problem/Incident
is caused by MDEV-20403 Assertion `0' or Assertion `btr_valid... Closed

 Description   

[updated with a more concise example inspired from tests]

Summary
In an AFTER UPDATE trigger, the new value for a timestamp ON UPDATE NOW() column is set to NOW() even when the row is not updated.

Steps to reproduce the issue

create table t1 (t timestamp, i int);
create trigger tr1 after update on t1 for each row set @new:=new.t;
insert t1 (t,i) values (0, 1);
update t1 set i = i;
-- Query OK, 0 rows affected (0.00 sec)
-- Rows matched: 1  Changed: 0  Warnings: 0
select @new, t from t1;

Expected result
Value of the t column is equal to the value of the new.t column in the trigger

+---------------------+---------------------+
| @new                | t                   |
+---------------------+---------------------+
| 0000-00-00 00:00:00 | 0000-00-00 00:00:00 |
+---------------------+---------------------+
1 row in set (0.00 sec)

Actual result
Value of the t column is NOT equal to the value of the new.t column in the trigger

+---------------------+---------------------+
| @new                | t                   |
+---------------------+---------------------+
| 2020-10-09 15:35:50 | 0000-00-00 00:00:00 |
+---------------------+---------------------+
1 row in set (0.00 sec)

Context

I've relied on this for years to distinguish updated from non updated rows, including in Mysql, but I skipped a lot of versions. The last working version for me was 10.3.17, and I found out about this when upgrading to 10.3.18 (the current stable Debian packaged version) so this is currently blocking for me.

After a chat on irc #maria@freenode I understand it might not be clear what is the expected behavior since it doesn't seem to be documented, but I'll make the case that the NEW value in the trigger should reflect the value that's persisted in the database.

Looking forward to reading some feedback on this!



 Comments   
Comment by Pierre-Jean Clement [ 2020-01-09 ]

Any thoughts on this? Anyone agrees this behaviour is not desirable?

Comment by Jon Armstrong [ 2020-01-09 ]

I agree, as we discussed. For the AFTER UPDATE behavior, the NEW values should reflect the actual values persisted.

I'm curious if the change in behavior was intentional or accidental. If intentional, what was the logic behind that decision?

Comment by Pierre-Jean Clement [ 2020-01-10 ]

I suspect this might originate from commit c7c481f4d918aaf42cef083b77ab551d69cdae58 as the commit message mentions this :

  • ON UPDATE DEFAULT NOW columns were updated after BEFORE triggers, so triggers didn't see the correct NEW value
Comment by Pierre-Jean Clement [ 2020-10-04 ]

This is semantically wrong to consider that BEFORE UPDATE TRIGGER can see values set by ON UPDATE.

Comment by Daniel Danek [ 2021-12-07 ]

Same problem in 10.6.5

Generated at Thu Feb 08 09:06:00 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.