Details
-
Bug
-
Status: Stalled (View Workflow)
-
Major
-
Resolution: Unresolved
-
10.2(EOL), 10.3(EOL), 10.4(EOL), 10.5, 10.6
-
None
Description
This bug is reported to fix the crash in InnoDB.
The root cause of the problem is however in the server, which allows to use in indexed virtual columns unsafe expressions depending on the session varianbles. For details see:
- MDEV-34037 - @@time_zone
- MDEV-34038 - @@dev_precision_increment
- MDEV-34039 - @@max_allowed_packet
The following scripts demonstrate the crash in InnoDB on @@time_zone change. However, a similar crash can also happen on @@div_precision_increment and @@max_allowed_packet. This needs to be checked.
This script demonstrates the crash:
SET time_zone='+00:00'; |
CREATE OR REPLACE TABLE t1 ( |
a DATETIME,
|
v TIMESTAMP GENERATED ALWAYS AS (a), |
KEY(v) |
);
|
INSERT INTO t1 (a) VALUES ('2001-01-01 10:20:30'); |
SET time_zone='+10:00'; |
UPDATE t1 SET a='2000-01-01 10:20:30'; |
crashes with the following stack trace:
#3 0x00007ffff76eba26 in __assert_fail () from /lib64/libc.so.6
|
#4 0x0000000000f9eede in row_upd_sec_index_entry (node=0x7fff68070158,
|
thr=0x7fff68073798)
|
at /home/bar/maria-git/server.10.4.frac2/storage/innobase/row/row0upd.cc:2425
|
#5 0x0000000000f9f6c9 in row_upd_sec_step (node=0x7fff68070158,
|
thr=0x7fff68073798)
|
at /home/bar/maria-git/server.10.4.frac2/storage/innobase/row/row0upd.cc:2539
|
#6 0x0000000000fa256e in row_upd (node=0x7fff68070158, thr=0x7fff68073798)
|
at /home/bar/maria-git/server.10.4.frac2/storage/innobase/row/row0upd.cc:3315
|
#7 0x0000000000fa29d5 in row_upd_step (thr=0x7fff68073798)
|
at /home/bar/maria-git/server.10.4.frac2/storage/innobase/row/row0upd.cc:3430
|
#8 0x0000000000f4134b in row_update_for_mysql (prebuilt=0x7fff6806f678)
|
at /home/bar/maria-git/server.10.4.frac2/storage/innobase/row/row0mysql.cc:1889
|
#9 0x0000000000da6a72 in ha_innobase::update_row (this=0x7fff6806dd88,
|
old_row=0x7fff680698e0 "\371\231g\202\245\036:O\315N\245\245\245\245\245\245\b\231\006h\377\177",
|
new_row=0x7fff680698d0 "\371\231dB\245\036\070mHN\245\245\245\245\245\245\371\231g\202\245\036:O\315N\245\245\245\245\245\245\b\231\006h\377\177")
|
at /home/bar/maria-git/server.10.4.frac2/storage/innobase/handler/ha_innodb.cc:8841
|
#10 0x0000000000b7195f in handler::ha_update_row (this=0x7fff6806dd88,
|
old_data=0x7fff680698e0 "\371\231g\202\245\036:O\315N\245\245\245\245\245\245\b\231\006h\377\177",
|
new_data=0x7fff680698d0 "\371\231dB\245\036\070mHN\245\245\245\245\245\245\371\231g\202\245\036:O\315N\245\245\245\245\245\245\b\231\006h\377\177")
|
at /home/bar/maria-git/server.10.4.frac2/sql/handler.cc:6719
|
#11 0x00000000009242f6 in mysql_update (thd=0x7fff68000d60,
|
table_list=0x7fff68014250, fields=..., values=..., conds=0x0, order_num=0,
|
order=0x0, limit=18446744073709551615, ignore=false,
|
found_return=0x7ffff41d6218, updated_return=0x7ffff41d6210)
|
at /home/bar/maria-git/server.10.4.frac2/sql/sql_update.cc:1047
|
This happens because DATETIME -> TIMESTAMP conversion depends in the @@time_zone system variable.
The same problem is repeatable with TIMESTAMP->DATETIME conversion:
SET time_zone='+00:00'; |
CREATE OR REPLACE TABLE t1 ( |
a TIMESTAMP, |
v DATETIME GENERATED ALWAYS AS (a), |
KEY(v) |
);
|
INSERT INTO t1 (a) VALUES ('2001-01-01 10:20:30'); |
SET time_zone='+10:00'; |
UPDATE t1 SET a='2000-01-01 10:20:30'; |
Attachments
Issue Links
- relates to
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- In Review
-
-
-
- Open
-
-
-
- Open
-
(7 relates to)
Activity
| Field | Original Value | New Value |
|---|---|---|
| Affects Version/s | 10.2 [ 14601 ] | |
| Affects Version/s | 10.3 [ 22126 ] |
| Affects Version/s | 10.5 [ 23123 ] |
| Fix Version/s | 10.2 [ 14601 ] |
| Link |
This issue relates to |
| Link |
This issue relates to |
| Link |
This issue relates to |
| Priority | Major [ 3 ] | Critical [ 2 ] |
| Description |
This script:
{code:sql} SET time_zone='+00:00'; CREATE OR REPLACE TABLE t1 ( a DATETIME, v TIMESTAMP GENERATED ALWAYS AS (a), KEY(v) ); INSERT INTO t1 (a) VALUES ('2001-01-01 10:20:30'); SET time_zone='+10:00'; UPDATE t1 SET a='2000-01-01 10:20:30'; {code} crashes with the following stack trace: {noformat} #3 0x00007ffff76eba26 in __assert_fail () from /lib64/libc.so.6 #4 0x0000000000f9eede in row_upd_sec_index_entry (node=0x7fff68070158, thr=0x7fff68073798) at /home/bar/maria-git/server.10.4.frac2/storage/innobase/row/row0upd.cc:2425 #5 0x0000000000f9f6c9 in row_upd_sec_step (node=0x7fff68070158, thr=0x7fff68073798) at /home/bar/maria-git/server.10.4.frac2/storage/innobase/row/row0upd.cc:2539 #6 0x0000000000fa256e in row_upd (node=0x7fff68070158, thr=0x7fff68073798) at /home/bar/maria-git/server.10.4.frac2/storage/innobase/row/row0upd.cc:3315 #7 0x0000000000fa29d5 in row_upd_step (thr=0x7fff68073798) at /home/bar/maria-git/server.10.4.frac2/storage/innobase/row/row0upd.cc:3430 #8 0x0000000000f4134b in row_update_for_mysql (prebuilt=0x7fff6806f678) at /home/bar/maria-git/server.10.4.frac2/storage/innobase/row/row0mysql.cc:1889 #9 0x0000000000da6a72 in ha_innobase::update_row (this=0x7fff6806dd88, old_row=0x7fff680698e0 "\371\231g\202\245\036:O\315N\245\245\245\245\245\245\b\231\006h\377\177", new_row=0x7fff680698d0 "\371\231dB\245\036\070mHN\245\245\245\245\245\245\371\231g\202\245\036:O\315N\245\245\245\245\245\245\b\231\006h\377\177") at /home/bar/maria-git/server.10.4.frac2/storage/innobase/handler/ha_innodb.cc:8841 #10 0x0000000000b7195f in handler::ha_update_row (this=0x7fff6806dd88, old_data=0x7fff680698e0 "\371\231g\202\245\036:O\315N\245\245\245\245\245\245\b\231\006h\377\177", new_data=0x7fff680698d0 "\371\231dB\245\036\070mHN\245\245\245\245\245\245\371\231g\202\245\036:O\315N\245\245\245\245\245\245\b\231\006h\377\177") at /home/bar/maria-git/server.10.4.frac2/sql/handler.cc:6719 #11 0x00000000009242f6 in mysql_update (thd=0x7fff68000d60, table_list=0x7fff68014250, fields=..., values=..., conds=0x0, order_num=0, order=0x0, limit=18446744073709551615, ignore=false, found_return=0x7ffff41d6218, updated_return=0x7ffff41d6210) at /home/bar/maria-git/server.10.4.frac2/sql/sql_update.cc:1047 {noformat} |
This script:
{code:sql} SET time_zone='+00:00'; CREATE OR REPLACE TABLE t1 ( a DATETIME, v TIMESTAMP GENERATED ALWAYS AS (a), KEY(v) ); INSERT INTO t1 (a) VALUES ('2001-01-01 10:20:30'); SET time_zone='+10:00'; UPDATE t1 SET a='2000-01-01 10:20:30'; {code} crashes with the following stack trace: {noformat} #3 0x00007ffff76eba26 in __assert_fail () from /lib64/libc.so.6 #4 0x0000000000f9eede in row_upd_sec_index_entry (node=0x7fff68070158, thr=0x7fff68073798) at /home/bar/maria-git/server.10.4.frac2/storage/innobase/row/row0upd.cc:2425 #5 0x0000000000f9f6c9 in row_upd_sec_step (node=0x7fff68070158, thr=0x7fff68073798) at /home/bar/maria-git/server.10.4.frac2/storage/innobase/row/row0upd.cc:2539 #6 0x0000000000fa256e in row_upd (node=0x7fff68070158, thr=0x7fff68073798) at /home/bar/maria-git/server.10.4.frac2/storage/innobase/row/row0upd.cc:3315 #7 0x0000000000fa29d5 in row_upd_step (thr=0x7fff68073798) at /home/bar/maria-git/server.10.4.frac2/storage/innobase/row/row0upd.cc:3430 #8 0x0000000000f4134b in row_update_for_mysql (prebuilt=0x7fff6806f678) at /home/bar/maria-git/server.10.4.frac2/storage/innobase/row/row0mysql.cc:1889 #9 0x0000000000da6a72 in ha_innobase::update_row (this=0x7fff6806dd88, old_row=0x7fff680698e0 "\371\231g\202\245\036:O\315N\245\245\245\245\245\245\b\231\006h\377\177", new_row=0x7fff680698d0 "\371\231dB\245\036\070mHN\245\245\245\245\245\245\371\231g\202\245\036:O\315N\245\245\245\245\245\245\b\231\006h\377\177") at /home/bar/maria-git/server.10.4.frac2/storage/innobase/handler/ha_innodb.cc:8841 #10 0x0000000000b7195f in handler::ha_update_row (this=0x7fff6806dd88, old_data=0x7fff680698e0 "\371\231g\202\245\036:O\315N\245\245\245\245\245\245\b\231\006h\377\177", new_data=0x7fff680698d0 "\371\231dB\245\036\070mHN\245\245\245\245\245\245\371\231g\202\245\036:O\315N\245\245\245\245\245\245\b\231\006h\377\177") at /home/bar/maria-git/server.10.4.frac2/sql/handler.cc:6719 #11 0x00000000009242f6 in mysql_update (thd=0x7fff68000d60, table_list=0x7fff68014250, fields=..., values=..., conds=0x0, order_num=0, order=0x0, limit=18446744073709551615, ignore=false, found_return=0x7ffff41d6218, updated_return=0x7ffff41d6210) at /home/bar/maria-git/server.10.4.frac2/sql/sql_update.cc:1047 {noformat} This happens because DATETIME -> TIMESTAMP conversion depends in the @@time_zone system variable. |
| Link |
This issue relates to |
| Comment |
[ The same problem is repeatable with the @@character_set_client variable change:
{code:sql} SET NAMES latin1; CREATE OR REPLACE TABLE t1 ( a VARCHAR(64), v VARCHAR(64) GENERATED ALWAYS AS (CHARSET('a')), KEY(v) ) ENGINE=InnoDB; INSERT INTO t1 (a) VALUES ('test1'); SET NAMES utf8; UPDATE t1 SET a='test2'; CHECK TABLE t1; {code} ] |
| Priority | Critical [ 2 ] | Major [ 3 ] |
| Link |
This issue relates to |
| Link |
This issue relates to |
| Link |
This issue relates to |
| Fix Version/s | 10.3 [ 22126 ] | |
| Fix Version/s | 10.4 [ 22408 ] | |
| Fix Version/s | 10.5 [ 23123 ] |
| Comment |
[ 10.2-10.5:
{noformat} SET time_zone='+00:00'; CREATE OR REPLACE TABLE t1 ( a DATETIME, v TIMESTAMP GENERATED ALWAYS AS (a), KEY(v) ); INSERT INTO t1 (a) VALUES ('2001-01-01 10:20:30'); SET time_zone='+10:00'; UPDATE t1 SET a='2000-01-01 10:20:30'; main.1_my [ fail ] Test ended at 2021-01-08 12:52:23 CURRENT_TEST: main.1_my mysqltest: At line 9: query 'UPDATE t1 SET a='2000-01-01 10:20:30'' failed: 126: Index for table './test/t1.MYI' is corrupt; try to repair it {noformat} ] |
| Affects Version/s | 10.6 [ 24028 ] |
| Fix Version/s | 10.6 [ 24028 ] |
| Status | Open [ 1 ] | Confirmed [ 10101 ] |
| Link |
This issue relates to |
| Assignee | Alexander Barkov [ bar ] | Oleksandr Byelkin [ sanja ] |
| Assignee | Oleksandr Byelkin [ sanja ] | Alexander Barkov [ bar ] |
| Workflow | MariaDB v3 [ 99708 ] | MariaDB v4 [ 144171 ] |
| Fix Version/s | 10.2 [ 14601 ] |
| Fix Version/s | 10.3 [ 22126 ] |
| Fix Version/s | 10.4 [ 22408 ] |
| Component/s | Temporal Types [ 11000 ] | |
| Component/s | Data types [ 13906 ] |
| Status | Confirmed [ 10101 ] | In Progress [ 3 ] |
| Link |
This issue relates to |
| Status | In Progress [ 3 ] | Stalled [ 10000 ] |
| Status | Stalled [ 10000 ] | In Progress [ 3 ] |
| Link | This issue relates to MDEV-34037 [ MDEV-34037 ] |
| Link | This issue relates to MDEV-34038 [ MDEV-34038 ] |
| Link | This issue relates to MDEV-34039 [ MDEV-34039 ] |
| Description |
This script:
{code:sql} SET time_zone='+00:00'; CREATE OR REPLACE TABLE t1 ( a DATETIME, v TIMESTAMP GENERATED ALWAYS AS (a), KEY(v) ); INSERT INTO t1 (a) VALUES ('2001-01-01 10:20:30'); SET time_zone='+10:00'; UPDATE t1 SET a='2000-01-01 10:20:30'; {code} crashes with the following stack trace: {noformat} #3 0x00007ffff76eba26 in __assert_fail () from /lib64/libc.so.6 #4 0x0000000000f9eede in row_upd_sec_index_entry (node=0x7fff68070158, thr=0x7fff68073798) at /home/bar/maria-git/server.10.4.frac2/storage/innobase/row/row0upd.cc:2425 #5 0x0000000000f9f6c9 in row_upd_sec_step (node=0x7fff68070158, thr=0x7fff68073798) at /home/bar/maria-git/server.10.4.frac2/storage/innobase/row/row0upd.cc:2539 #6 0x0000000000fa256e in row_upd (node=0x7fff68070158, thr=0x7fff68073798) at /home/bar/maria-git/server.10.4.frac2/storage/innobase/row/row0upd.cc:3315 #7 0x0000000000fa29d5 in row_upd_step (thr=0x7fff68073798) at /home/bar/maria-git/server.10.4.frac2/storage/innobase/row/row0upd.cc:3430 #8 0x0000000000f4134b in row_update_for_mysql (prebuilt=0x7fff6806f678) at /home/bar/maria-git/server.10.4.frac2/storage/innobase/row/row0mysql.cc:1889 #9 0x0000000000da6a72 in ha_innobase::update_row (this=0x7fff6806dd88, old_row=0x7fff680698e0 "\371\231g\202\245\036:O\315N\245\245\245\245\245\245\b\231\006h\377\177", new_row=0x7fff680698d0 "\371\231dB\245\036\070mHN\245\245\245\245\245\245\371\231g\202\245\036:O\315N\245\245\245\245\245\245\b\231\006h\377\177") at /home/bar/maria-git/server.10.4.frac2/storage/innobase/handler/ha_innodb.cc:8841 #10 0x0000000000b7195f in handler::ha_update_row (this=0x7fff6806dd88, old_data=0x7fff680698e0 "\371\231g\202\245\036:O\315N\245\245\245\245\245\245\b\231\006h\377\177", new_data=0x7fff680698d0 "\371\231dB\245\036\070mHN\245\245\245\245\245\245\371\231g\202\245\036:O\315N\245\245\245\245\245\245\b\231\006h\377\177") at /home/bar/maria-git/server.10.4.frac2/sql/handler.cc:6719 #11 0x00000000009242f6 in mysql_update (thd=0x7fff68000d60, table_list=0x7fff68014250, fields=..., values=..., conds=0x0, order_num=0, order=0x0, limit=18446744073709551615, ignore=false, found_return=0x7ffff41d6218, updated_return=0x7ffff41d6210) at /home/bar/maria-git/server.10.4.frac2/sql/sql_update.cc:1047 {noformat} This happens because DATETIME -> TIMESTAMP conversion depends in the @@time_zone system variable. |
This bug is reported to fix the crash in InnoDB.
The root cause of the problem is that the server allows to use unsafe expressions in indexed virtual columns. For details see: - MDEV-34037 - MDEV-34038 - MDEV-34039 This script demonstrates the crash: {code:sql} SET time_zone='+00:00'; CREATE OR REPLACE TABLE t1 ( a DATETIME, v TIMESTAMP GENERATED ALWAYS AS (a), KEY(v) ); INSERT INTO t1 (a) VALUES ('2001-01-01 10:20:30'); SET time_zone='+10:00'; UPDATE t1 SET a='2000-01-01 10:20:30'; {code} crashes with the following stack trace: {noformat} #3 0x00007ffff76eba26 in __assert_fail () from /lib64/libc.so.6 #4 0x0000000000f9eede in row_upd_sec_index_entry (node=0x7fff68070158, thr=0x7fff68073798) at /home/bar/maria-git/server.10.4.frac2/storage/innobase/row/row0upd.cc:2425 #5 0x0000000000f9f6c9 in row_upd_sec_step (node=0x7fff68070158, thr=0x7fff68073798) at /home/bar/maria-git/server.10.4.frac2/storage/innobase/row/row0upd.cc:2539 #6 0x0000000000fa256e in row_upd (node=0x7fff68070158, thr=0x7fff68073798) at /home/bar/maria-git/server.10.4.frac2/storage/innobase/row/row0upd.cc:3315 #7 0x0000000000fa29d5 in row_upd_step (thr=0x7fff68073798) at /home/bar/maria-git/server.10.4.frac2/storage/innobase/row/row0upd.cc:3430 #8 0x0000000000f4134b in row_update_for_mysql (prebuilt=0x7fff6806f678) at /home/bar/maria-git/server.10.4.frac2/storage/innobase/row/row0mysql.cc:1889 #9 0x0000000000da6a72 in ha_innobase::update_row (this=0x7fff6806dd88, old_row=0x7fff680698e0 "\371\231g\202\245\036:O\315N\245\245\245\245\245\245\b\231\006h\377\177", new_row=0x7fff680698d0 "\371\231dB\245\036\070mHN\245\245\245\245\245\245\371\231g\202\245\036:O\315N\245\245\245\245\245\245\b\231\006h\377\177") at /home/bar/maria-git/server.10.4.frac2/storage/innobase/handler/ha_innodb.cc:8841 #10 0x0000000000b7195f in handler::ha_update_row (this=0x7fff6806dd88, old_data=0x7fff680698e0 "\371\231g\202\245\036:O\315N\245\245\245\245\245\245\b\231\006h\377\177", new_data=0x7fff680698d0 "\371\231dB\245\036\070mHN\245\245\245\245\245\245\371\231g\202\245\036:O\315N\245\245\245\245\245\245\b\231\006h\377\177") at /home/bar/maria-git/server.10.4.frac2/sql/handler.cc:6719 #11 0x00000000009242f6 in mysql_update (thd=0x7fff68000d60, table_list=0x7fff68014250, fields=..., values=..., conds=0x0, order_num=0, order=0x0, limit=18446744073709551615, ignore=false, found_return=0x7ffff41d6218, updated_return=0x7ffff41d6210) at /home/bar/maria-git/server.10.4.frac2/sql/sql_update.cc:1047 {noformat} This happens because DATETIME -> TIMESTAMP conversion depends in the @@time_zone system variable. |
| Description |
This bug is reported to fix the crash in InnoDB.
The root cause of the problem is that the server allows to use unsafe expressions in indexed virtual columns. For details see: - MDEV-34037 - MDEV-34038 - MDEV-34039 This script demonstrates the crash: {code:sql} SET time_zone='+00:00'; CREATE OR REPLACE TABLE t1 ( a DATETIME, v TIMESTAMP GENERATED ALWAYS AS (a), KEY(v) ); INSERT INTO t1 (a) VALUES ('2001-01-01 10:20:30'); SET time_zone='+10:00'; UPDATE t1 SET a='2000-01-01 10:20:30'; {code} crashes with the following stack trace: {noformat} #3 0x00007ffff76eba26 in __assert_fail () from /lib64/libc.so.6 #4 0x0000000000f9eede in row_upd_sec_index_entry (node=0x7fff68070158, thr=0x7fff68073798) at /home/bar/maria-git/server.10.4.frac2/storage/innobase/row/row0upd.cc:2425 #5 0x0000000000f9f6c9 in row_upd_sec_step (node=0x7fff68070158, thr=0x7fff68073798) at /home/bar/maria-git/server.10.4.frac2/storage/innobase/row/row0upd.cc:2539 #6 0x0000000000fa256e in row_upd (node=0x7fff68070158, thr=0x7fff68073798) at /home/bar/maria-git/server.10.4.frac2/storage/innobase/row/row0upd.cc:3315 #7 0x0000000000fa29d5 in row_upd_step (thr=0x7fff68073798) at /home/bar/maria-git/server.10.4.frac2/storage/innobase/row/row0upd.cc:3430 #8 0x0000000000f4134b in row_update_for_mysql (prebuilt=0x7fff6806f678) at /home/bar/maria-git/server.10.4.frac2/storage/innobase/row/row0mysql.cc:1889 #9 0x0000000000da6a72 in ha_innobase::update_row (this=0x7fff6806dd88, old_row=0x7fff680698e0 "\371\231g\202\245\036:O\315N\245\245\245\245\245\245\b\231\006h\377\177", new_row=0x7fff680698d0 "\371\231dB\245\036\070mHN\245\245\245\245\245\245\371\231g\202\245\036:O\315N\245\245\245\245\245\245\b\231\006h\377\177") at /home/bar/maria-git/server.10.4.frac2/storage/innobase/handler/ha_innodb.cc:8841 #10 0x0000000000b7195f in handler::ha_update_row (this=0x7fff6806dd88, old_data=0x7fff680698e0 "\371\231g\202\245\036:O\315N\245\245\245\245\245\245\b\231\006h\377\177", new_data=0x7fff680698d0 "\371\231dB\245\036\070mHN\245\245\245\245\245\245\371\231g\202\245\036:O\315N\245\245\245\245\245\245\b\231\006h\377\177") at /home/bar/maria-git/server.10.4.frac2/sql/handler.cc:6719 #11 0x00000000009242f6 in mysql_update (thd=0x7fff68000d60, table_list=0x7fff68014250, fields=..., values=..., conds=0x0, order_num=0, order=0x0, limit=18446744073709551615, ignore=false, found_return=0x7ffff41d6218, updated_return=0x7ffff41d6210) at /home/bar/maria-git/server.10.4.frac2/sql/sql_update.cc:1047 {noformat} This happens because DATETIME -> TIMESTAMP conversion depends in the @@time_zone system variable. |
This bug is reported to fix the crash in InnoDB.
The root cause of the problem is that the server allows to use in indexed virtual columns unsafe expressions depending on the session varianbles. For details see: - MDEV-34037 - @@time_zone - MDEV-34038 - @@dev_precision_increment - MDEV-34039 - @@max_allowed_packet The following scripts demonstrate the crash in InnoDB on @@time_zone change. However, a similar crash can also happen on @@div_precision_increment and @@max_allowed_packet. This needs to be checked. This script demonstrates the crash: {code:sql} SET time_zone='+00:00'; CREATE OR REPLACE TABLE t1 ( a DATETIME, v TIMESTAMP GENERATED ALWAYS AS (a), KEY(v) ); INSERT INTO t1 (a) VALUES ('2001-01-01 10:20:30'); SET time_zone='+10:00'; UPDATE t1 SET a='2000-01-01 10:20:30'; {code} crashes with the following stack trace: {noformat} #3 0x00007ffff76eba26 in __assert_fail () from /lib64/libc.so.6 #4 0x0000000000f9eede in row_upd_sec_index_entry (node=0x7fff68070158, thr=0x7fff68073798) at /home/bar/maria-git/server.10.4.frac2/storage/innobase/row/row0upd.cc:2425 #5 0x0000000000f9f6c9 in row_upd_sec_step (node=0x7fff68070158, thr=0x7fff68073798) at /home/bar/maria-git/server.10.4.frac2/storage/innobase/row/row0upd.cc:2539 #6 0x0000000000fa256e in row_upd (node=0x7fff68070158, thr=0x7fff68073798) at /home/bar/maria-git/server.10.4.frac2/storage/innobase/row/row0upd.cc:3315 #7 0x0000000000fa29d5 in row_upd_step (thr=0x7fff68073798) at /home/bar/maria-git/server.10.4.frac2/storage/innobase/row/row0upd.cc:3430 #8 0x0000000000f4134b in row_update_for_mysql (prebuilt=0x7fff6806f678) at /home/bar/maria-git/server.10.4.frac2/storage/innobase/row/row0mysql.cc:1889 #9 0x0000000000da6a72 in ha_innobase::update_row (this=0x7fff6806dd88, old_row=0x7fff680698e0 "\371\231g\202\245\036:O\315N\245\245\245\245\245\245\b\231\006h\377\177", new_row=0x7fff680698d0 "\371\231dB\245\036\070mHN\245\245\245\245\245\245\371\231g\202\245\036:O\315N\245\245\245\245\245\245\b\231\006h\377\177") at /home/bar/maria-git/server.10.4.frac2/storage/innobase/handler/ha_innodb.cc:8841 #10 0x0000000000b7195f in handler::ha_update_row (this=0x7fff6806dd88, old_data=0x7fff680698e0 "\371\231g\202\245\036:O\315N\245\245\245\245\245\245\b\231\006h\377\177", new_data=0x7fff680698d0 "\371\231dB\245\036\070mHN\245\245\245\245\245\245\371\231g\202\245\036:O\315N\245\245\245\245\245\245\b\231\006h\377\177") at /home/bar/maria-git/server.10.4.frac2/sql/handler.cc:6719 #11 0x00000000009242f6 in mysql_update (thd=0x7fff68000d60, table_list=0x7fff68014250, fields=..., values=..., conds=0x0, order_num=0, order=0x0, limit=18446744073709551615, ignore=false, found_return=0x7ffff41d6218, updated_return=0x7ffff41d6210) at /home/bar/maria-git/server.10.4.frac2/sql/sql_update.cc:1047 {noformat} This happens because DATETIME -> TIMESTAMP conversion depends in the @@time_zone system variable. |
| Comment |
[ The problem is also repeatable with the @@max_allowed_packet variable with MyISAM:
{code:sql} SET GLOBAL max_allowed_packet=16777216*2; KILL CONNECTION_ID(); CREATE OR REPLACE TABLE t1 ( a VARCHAR(64), v INT GENERATED ALWAYS AS (LENGTH(REPEAT(a,16777216*2))), KEY(v) ) ENGINE=MyISAM; INSERT INTO t1 (a) VALUES ('a'); SELECT * FROM t1; KILL CONNECTION_ID(); SET GLOBAL max_allowed_packet=16777216; KILL CONNECTION_ID(); CHECK TABLE t1; {code} {noformat} +---------+-------+----------+------------------------------------------------------------------------------+ | Table | Op | Msg_type | Msg_text | +---------+-------+----------+------------------------------------------------------------------------------+ | test.t1 | check | error | Checksum for key: 1 doesn't match checksum for records | | test.t1 | check | Warning | Result of repeat() was larger than max_allowed_packet (16777216) - truncated | | test.t1 | check | error | Corrupt | +---------+-------+----------+------------------------------------------------------------------------------+ {noformat} ] |
| Comment |
[ A similar problem is repeatable with @@dev_precision_increment with MyISAM
{code:sql} SET @@div_precision_increment=4; CREATE OR REPLACE TABLE t1 ( a INT, v INT GENERATED ALWAYS AS (LENGTH(a/3)), KEY(v) ) ENGINE=MyISAM; INSERT INTO t1 (a) VALUES (1); SELECT * FROM t1; FLUSH TABLES; SET @@div_precision_increment=8; SELECT * FROM t1; CHECK TABLE t1; {code} {noformat} +---------+-------+----------+---------------------------------------------------------+ | Table | Op | Msg_type | Msg_text | +---------+-------+----------+---------------------------------------------------------+ | test.t1 | check | error | Checksum for key: 1 doesn't match checksum for records | | test.t1 | check | error | Corrupt | +---------+-------+----------+---------------------------------------------------------+ {noformat} Also repeatable with these scripts: {code:sql} SET @@div_precision_increment=4; CREATE OR REPLACE TABLE t1 ( a INT, v VARCHAR(100) GENERATED ALWAYS AS (a/3.000), KEY(v) ) ENGINE=MyISAM; INSERT INTO t1 (a) VALUES (1); SELECT * FROM t1; FLUSH TABLES; SET @@div_precision_increment=8; SELECT * FROM t1; CHECK TABLE t1; {code} {code:sql} SET @@div_precision_increment=4; CREATE OR REPLACE TABLE t1 ( a INT, v DECIMAL(48,30) GENERATED ALWAYS AS (a/3.000), KEY(v) ) ENGINE=MyISAM; INSERT INTO t1 (a) VALUES (1); SELECT * FROM t1; FLUSH TABLES; SET @@div_precision_increment=8; SELECT * FROM t1; CHECK TABLE t1; {code} ] |
| Comment |
[ The same problem is repeatable with DECIMAL->TIMESTAMP conversion:
{code:sql} SET time_zone='+00:00'; CREATE OR REPLACE TABLE t1 ( a DECIMAL(32,0), v TIMESTAMP GENERATED ALWAYS AS (a), KEY(v) ); INSERT INTO t1 (a) VALUES (20010101102030); SET time_zone='+10:00'; UPDATE t1 SET a='20000101102030'; {code} ] |
| Comment |
[ The same problem is repeatable with TIMESTAMP->DECIMAL conversion, because TIMESTAMP is first converted to DATETIME, then DATETIME is converted to DECIMAL:
{code:sql} SET time_zone='+00:00'; CREATE OR REPLACE TABLE t1 ( a TIMESTAMP, v DECIMAL(32,0) GENERATED ALWAYS AS (a), KEY(v) ); INSERT INTO t1 (a) VALUES ('2001-01-01 10:20:30'); SET time_zone='+10:00'; UPDATE t1 SET a='2000-01-01 10:20:30'; {code} ] |
| Description |
This bug is reported to fix the crash in InnoDB.
The root cause of the problem is that the server allows to use in indexed virtual columns unsafe expressions depending on the session varianbles. For details see: - MDEV-34037 - @@time_zone - MDEV-34038 - @@dev_precision_increment - MDEV-34039 - @@max_allowed_packet The following scripts demonstrate the crash in InnoDB on @@time_zone change. However, a similar crash can also happen on @@div_precision_increment and @@max_allowed_packet. This needs to be checked. This script demonstrates the crash: {code:sql} SET time_zone='+00:00'; CREATE OR REPLACE TABLE t1 ( a DATETIME, v TIMESTAMP GENERATED ALWAYS AS (a), KEY(v) ); INSERT INTO t1 (a) VALUES ('2001-01-01 10:20:30'); SET time_zone='+10:00'; UPDATE t1 SET a='2000-01-01 10:20:30'; {code} crashes with the following stack trace: {noformat} #3 0x00007ffff76eba26 in __assert_fail () from /lib64/libc.so.6 #4 0x0000000000f9eede in row_upd_sec_index_entry (node=0x7fff68070158, thr=0x7fff68073798) at /home/bar/maria-git/server.10.4.frac2/storage/innobase/row/row0upd.cc:2425 #5 0x0000000000f9f6c9 in row_upd_sec_step (node=0x7fff68070158, thr=0x7fff68073798) at /home/bar/maria-git/server.10.4.frac2/storage/innobase/row/row0upd.cc:2539 #6 0x0000000000fa256e in row_upd (node=0x7fff68070158, thr=0x7fff68073798) at /home/bar/maria-git/server.10.4.frac2/storage/innobase/row/row0upd.cc:3315 #7 0x0000000000fa29d5 in row_upd_step (thr=0x7fff68073798) at /home/bar/maria-git/server.10.4.frac2/storage/innobase/row/row0upd.cc:3430 #8 0x0000000000f4134b in row_update_for_mysql (prebuilt=0x7fff6806f678) at /home/bar/maria-git/server.10.4.frac2/storage/innobase/row/row0mysql.cc:1889 #9 0x0000000000da6a72 in ha_innobase::update_row (this=0x7fff6806dd88, old_row=0x7fff680698e0 "\371\231g\202\245\036:O\315N\245\245\245\245\245\245\b\231\006h\377\177", new_row=0x7fff680698d0 "\371\231dB\245\036\070mHN\245\245\245\245\245\245\371\231g\202\245\036:O\315N\245\245\245\245\245\245\b\231\006h\377\177") at /home/bar/maria-git/server.10.4.frac2/storage/innobase/handler/ha_innodb.cc:8841 #10 0x0000000000b7195f in handler::ha_update_row (this=0x7fff6806dd88, old_data=0x7fff680698e0 "\371\231g\202\245\036:O\315N\245\245\245\245\245\245\b\231\006h\377\177", new_data=0x7fff680698d0 "\371\231dB\245\036\070mHN\245\245\245\245\245\245\371\231g\202\245\036:O\315N\245\245\245\245\245\245\b\231\006h\377\177") at /home/bar/maria-git/server.10.4.frac2/sql/handler.cc:6719 #11 0x00000000009242f6 in mysql_update (thd=0x7fff68000d60, table_list=0x7fff68014250, fields=..., values=..., conds=0x0, order_num=0, order=0x0, limit=18446744073709551615, ignore=false, found_return=0x7ffff41d6218, updated_return=0x7ffff41d6210) at /home/bar/maria-git/server.10.4.frac2/sql/sql_update.cc:1047 {noformat} This happens because DATETIME -> TIMESTAMP conversion depends in the @@time_zone system variable. |
This bug is reported to fix the crash in InnoDB.
The root cause of the problem is that the server allows to use in indexed virtual columns unsafe expressions depending on the session varianbles. For details see: - MDEV-34037 - @@time_zone - MDEV-34038 - @@dev_precision_increment - MDEV-34039 - @@max_allowed_packet The following scripts demonstrate the crash in InnoDB on @@time_zone change. However, a similar crash can also happen on @@div_precision_increment and @@max_allowed_packet. This needs to be checked. This script demonstrates the crash: {code:sql} SET time_zone='+00:00'; CREATE OR REPLACE TABLE t1 ( a DATETIME, v TIMESTAMP GENERATED ALWAYS AS (a), KEY(v) ); INSERT INTO t1 (a) VALUES ('2001-01-01 10:20:30'); SET time_zone='+10:00'; UPDATE t1 SET a='2000-01-01 10:20:30'; {code} crashes with the following stack trace: {noformat} #3 0x00007ffff76eba26 in __assert_fail () from /lib64/libc.so.6 #4 0x0000000000f9eede in row_upd_sec_index_entry (node=0x7fff68070158, thr=0x7fff68073798) at /home/bar/maria-git/server.10.4.frac2/storage/innobase/row/row0upd.cc:2425 #5 0x0000000000f9f6c9 in row_upd_sec_step (node=0x7fff68070158, thr=0x7fff68073798) at /home/bar/maria-git/server.10.4.frac2/storage/innobase/row/row0upd.cc:2539 #6 0x0000000000fa256e in row_upd (node=0x7fff68070158, thr=0x7fff68073798) at /home/bar/maria-git/server.10.4.frac2/storage/innobase/row/row0upd.cc:3315 #7 0x0000000000fa29d5 in row_upd_step (thr=0x7fff68073798) at /home/bar/maria-git/server.10.4.frac2/storage/innobase/row/row0upd.cc:3430 #8 0x0000000000f4134b in row_update_for_mysql (prebuilt=0x7fff6806f678) at /home/bar/maria-git/server.10.4.frac2/storage/innobase/row/row0mysql.cc:1889 #9 0x0000000000da6a72 in ha_innobase::update_row (this=0x7fff6806dd88, old_row=0x7fff680698e0 "\371\231g\202\245\036:O\315N\245\245\245\245\245\245\b\231\006h\377\177", new_row=0x7fff680698d0 "\371\231dB\245\036\070mHN\245\245\245\245\245\245\371\231g\202\245\036:O\315N\245\245\245\245\245\245\b\231\006h\377\177") at /home/bar/maria-git/server.10.4.frac2/storage/innobase/handler/ha_innodb.cc:8841 #10 0x0000000000b7195f in handler::ha_update_row (this=0x7fff6806dd88, old_data=0x7fff680698e0 "\371\231g\202\245\036:O\315N\245\245\245\245\245\245\b\231\006h\377\177", new_data=0x7fff680698d0 "\371\231dB\245\036\070mHN\245\245\245\245\245\245\371\231g\202\245\036:O\315N\245\245\245\245\245\245\b\231\006h\377\177") at /home/bar/maria-git/server.10.4.frac2/sql/handler.cc:6719 #11 0x00000000009242f6 in mysql_update (thd=0x7fff68000d60, table_list=0x7fff68014250, fields=..., values=..., conds=0x0, order_num=0, order=0x0, limit=18446744073709551615, ignore=false, found_return=0x7ffff41d6218, updated_return=0x7ffff41d6210) at /home/bar/maria-git/server.10.4.frac2/sql/sql_update.cc:1047 {noformat} This happens because DATETIME -> TIMESTAMP conversion depends in the @@time_zone system variable. The same problem is repeatable with TIMESTAMP->DATETIME conversion: {code:sql} SET time_zone='+00:00'; CREATE OR REPLACE TABLE t1 ( a TIMESTAMP, v DATETIME GENERATED ALWAYS AS (a), KEY(v) ); INSERT INTO t1 (a) VALUES ('2001-01-01 10:20:30'); SET time_zone='+10:00'; UPDATE t1 SET a='2000-01-01 10:20:30'; {code} |
| Comment |
[ The same problem is repeatable with TIMESTAMP->DATETIME conversion:
{code:sql} SET time_zone='+00:00'; CREATE OR REPLACE TABLE t1 ( a TIMESTAMP, v DATETIME GENERATED ALWAYS AS (a), KEY(v) ); INSERT INTO t1 (a) VALUES ('2001-01-01 10:20:30'); SET time_zone='+10:00'; UPDATE t1 SET a='2000-01-01 10:20:30'; {code} ] |
| Description |
This bug is reported to fix the crash in InnoDB.
The root cause of the problem is that the server allows to use in indexed virtual columns unsafe expressions depending on the session varianbles. For details see: - MDEV-34037 - @@time_zone - MDEV-34038 - @@dev_precision_increment - MDEV-34039 - @@max_allowed_packet The following scripts demonstrate the crash in InnoDB on @@time_zone change. However, a similar crash can also happen on @@div_precision_increment and @@max_allowed_packet. This needs to be checked. This script demonstrates the crash: {code:sql} SET time_zone='+00:00'; CREATE OR REPLACE TABLE t1 ( a DATETIME, v TIMESTAMP GENERATED ALWAYS AS (a), KEY(v) ); INSERT INTO t1 (a) VALUES ('2001-01-01 10:20:30'); SET time_zone='+10:00'; UPDATE t1 SET a='2000-01-01 10:20:30'; {code} crashes with the following stack trace: {noformat} #3 0x00007ffff76eba26 in __assert_fail () from /lib64/libc.so.6 #4 0x0000000000f9eede in row_upd_sec_index_entry (node=0x7fff68070158, thr=0x7fff68073798) at /home/bar/maria-git/server.10.4.frac2/storage/innobase/row/row0upd.cc:2425 #5 0x0000000000f9f6c9 in row_upd_sec_step (node=0x7fff68070158, thr=0x7fff68073798) at /home/bar/maria-git/server.10.4.frac2/storage/innobase/row/row0upd.cc:2539 #6 0x0000000000fa256e in row_upd (node=0x7fff68070158, thr=0x7fff68073798) at /home/bar/maria-git/server.10.4.frac2/storage/innobase/row/row0upd.cc:3315 #7 0x0000000000fa29d5 in row_upd_step (thr=0x7fff68073798) at /home/bar/maria-git/server.10.4.frac2/storage/innobase/row/row0upd.cc:3430 #8 0x0000000000f4134b in row_update_for_mysql (prebuilt=0x7fff6806f678) at /home/bar/maria-git/server.10.4.frac2/storage/innobase/row/row0mysql.cc:1889 #9 0x0000000000da6a72 in ha_innobase::update_row (this=0x7fff6806dd88, old_row=0x7fff680698e0 "\371\231g\202\245\036:O\315N\245\245\245\245\245\245\b\231\006h\377\177", new_row=0x7fff680698d0 "\371\231dB\245\036\070mHN\245\245\245\245\245\245\371\231g\202\245\036:O\315N\245\245\245\245\245\245\b\231\006h\377\177") at /home/bar/maria-git/server.10.4.frac2/storage/innobase/handler/ha_innodb.cc:8841 #10 0x0000000000b7195f in handler::ha_update_row (this=0x7fff6806dd88, old_data=0x7fff680698e0 "\371\231g\202\245\036:O\315N\245\245\245\245\245\245\b\231\006h\377\177", new_data=0x7fff680698d0 "\371\231dB\245\036\070mHN\245\245\245\245\245\245\371\231g\202\245\036:O\315N\245\245\245\245\245\245\b\231\006h\377\177") at /home/bar/maria-git/server.10.4.frac2/sql/handler.cc:6719 #11 0x00000000009242f6 in mysql_update (thd=0x7fff68000d60, table_list=0x7fff68014250, fields=..., values=..., conds=0x0, order_num=0, order=0x0, limit=18446744073709551615, ignore=false, found_return=0x7ffff41d6218, updated_return=0x7ffff41d6210) at /home/bar/maria-git/server.10.4.frac2/sql/sql_update.cc:1047 {noformat} This happens because DATETIME -> TIMESTAMP conversion depends in the @@time_zone system variable. The same problem is repeatable with TIMESTAMP->DATETIME conversion: {code:sql} SET time_zone='+00:00'; CREATE OR REPLACE TABLE t1 ( a TIMESTAMP, v DATETIME GENERATED ALWAYS AS (a), KEY(v) ); INSERT INTO t1 (a) VALUES ('2001-01-01 10:20:30'); SET time_zone='+10:00'; UPDATE t1 SET a='2000-01-01 10:20:30'; {code} |
This bug is reported to fix the crash in InnoDB.
The root cause of the problem is however in the server, which allows to use in indexed virtual columns unsafe expressions depending on the session varianbles. For details see: - MDEV-34037 - @@time_zone - MDEV-34038 - @@dev_precision_increment - MDEV-34039 - @@max_allowed_packet The following scripts demonstrate the crash in InnoDB on @@time_zone change. However, a similar crash can also happen on @@div_precision_increment and @@max_allowed_packet. This needs to be checked. This script demonstrates the crash: {code:sql} SET time_zone='+00:00'; CREATE OR REPLACE TABLE t1 ( a DATETIME, v TIMESTAMP GENERATED ALWAYS AS (a), KEY(v) ); INSERT INTO t1 (a) VALUES ('2001-01-01 10:20:30'); SET time_zone='+10:00'; UPDATE t1 SET a='2000-01-01 10:20:30'; {code} crashes with the following stack trace: {noformat} #3 0x00007ffff76eba26 in __assert_fail () from /lib64/libc.so.6 #4 0x0000000000f9eede in row_upd_sec_index_entry (node=0x7fff68070158, thr=0x7fff68073798) at /home/bar/maria-git/server.10.4.frac2/storage/innobase/row/row0upd.cc:2425 #5 0x0000000000f9f6c9 in row_upd_sec_step (node=0x7fff68070158, thr=0x7fff68073798) at /home/bar/maria-git/server.10.4.frac2/storage/innobase/row/row0upd.cc:2539 #6 0x0000000000fa256e in row_upd (node=0x7fff68070158, thr=0x7fff68073798) at /home/bar/maria-git/server.10.4.frac2/storage/innobase/row/row0upd.cc:3315 #7 0x0000000000fa29d5 in row_upd_step (thr=0x7fff68073798) at /home/bar/maria-git/server.10.4.frac2/storage/innobase/row/row0upd.cc:3430 #8 0x0000000000f4134b in row_update_for_mysql (prebuilt=0x7fff6806f678) at /home/bar/maria-git/server.10.4.frac2/storage/innobase/row/row0mysql.cc:1889 #9 0x0000000000da6a72 in ha_innobase::update_row (this=0x7fff6806dd88, old_row=0x7fff680698e0 "\371\231g\202\245\036:O\315N\245\245\245\245\245\245\b\231\006h\377\177", new_row=0x7fff680698d0 "\371\231dB\245\036\070mHN\245\245\245\245\245\245\371\231g\202\245\036:O\315N\245\245\245\245\245\245\b\231\006h\377\177") at /home/bar/maria-git/server.10.4.frac2/storage/innobase/handler/ha_innodb.cc:8841 #10 0x0000000000b7195f in handler::ha_update_row (this=0x7fff6806dd88, old_data=0x7fff680698e0 "\371\231g\202\245\036:O\315N\245\245\245\245\245\245\b\231\006h\377\177", new_data=0x7fff680698d0 "\371\231dB\245\036\070mHN\245\245\245\245\245\245\371\231g\202\245\036:O\315N\245\245\245\245\245\245\b\231\006h\377\177") at /home/bar/maria-git/server.10.4.frac2/sql/handler.cc:6719 #11 0x00000000009242f6 in mysql_update (thd=0x7fff68000d60, table_list=0x7fff68014250, fields=..., values=..., conds=0x0, order_num=0, order=0x0, limit=18446744073709551615, ignore=false, found_return=0x7ffff41d6218, updated_return=0x7ffff41d6210) at /home/bar/maria-git/server.10.4.frac2/sql/sql_update.cc:1047 {noformat} This happens because DATETIME -> TIMESTAMP conversion depends in the @@time_zone system variable. The same problem is repeatable with TIMESTAMP->DATETIME conversion: {code:sql} SET time_zone='+00:00'; CREATE OR REPLACE TABLE t1 ( a TIMESTAMP, v DATETIME GENERATED ALWAYS AS (a), KEY(v) ); INSERT INTO t1 (a) VALUES ('2001-01-01 10:20:30'); SET time_zone='+10:00'; UPDATE t1 SET a='2000-01-01 10:20:30'; {code} |
| Assignee | Alexander Barkov [ bar ] | Marko Mäkelä [ marko ] |
The assertion is there so that we could catch index corruption more prominently in debug instrumented builds. Theoretically, we could apply the following patch to make the assertion failure go away:
diff --git a/storage/innobase/row/row0upd.cc b/storage/innobase/row/row0upd.cc
|
index 4e2a9770aff..e0acd3df135 100644
|
--- a/storage/innobase/row/row0upd.cc
|
+++ b/storage/innobase/row/row0upd.cc
|
@@ -2112,7 +2112,7 @@ row_upd_sec_index_entry(
|
mtr_commit(&mtr);
|
mtr_start(&mtr);
|
ut_ad(btr_validate_index(index, 0) == DB_SUCCESS);
|
- ut_ad(0);
|
+ ut_ad(index->has_virtual()); // tolerate some known bugs
|
#endif /* UNIV_DEBUG */
|
break;
|
case ROW_FOUND: |
But wouldn’t that then lead to more bugs of this kind to be ignored?
| Status | In Progress [ 3 ] | Stalled [ 10000 ] |
also on 10.6:
2021-08-26 12:54:22 4 [ERROR] InnoDB: Record in index `v` of table `test`.`t1` was not found on update: TUPLE (info_bits=0, 2 fields): {[4]:O N(0x3A4FCD4E),[6] (0x000000000200)} at: COMPACT RECORD(info_bits=0, 1 fields): {[8]infimum (0x696E66696D756D00)}mariadbd: /10.6/src/storage/innobase/row/row0upd.cc:2051: dberr_t row_upd_sec_index_entry(upd_node_t*, que_thr_t*): Assertion `0' failed.210826 12:54:22 [ERROR] mysqld got signal 6 ;Server version: 10.6.5-MariaDB-debug-loglinux/raise.c:51(__GI_raise)[0x7f7c31eb218b]stdlib/abort.c:81(__GI_abort)[0x7f7c31e91859]intl/loadmsgcat.c:509(get_sysdep_segment_value)[0x7f7c31e91729]:0(__GI___assert_fail)[0x7f7c31ea2f36]row/row0upd.cc:2055(row_upd_sec_index_entry(upd_node_t*, que_thr_t*))[0x55fc88ed6a25]row/row0upd.cc:2200(row_upd_sec_step(upd_node_t*, que_thr_t*))[0x55fc88ed7a30]row/row0upd.cc:2936(row_upd(upd_node_t*, que_thr_t*))[0x55fc88edccbc]row/row0upd.cc:3051(row_upd_step(que_thr_t*))[0x55fc88edd7c1]row/row0mysql.cc:1723(row_update_for_mysql(row_prebuilt_t*))[0x55fc88e329f1]handler/ha_innodb.cc:8554(ha_innobase::update_row(unsigned char const*, unsigned char const*))[0x55fc88a8b2a0]sql/handler.cc:7567(handler::ha_update_row(unsigned char const*, unsigned char const*))[0x55fc87fa981f]sql/sql_update.cc:1081(mysql_update(THD*, TABLE_LIST*, List<Item>&, List<Item>&, Item*, unsigned int, st_order*, unsigned long long, bool, unsigned long long*, unsigned long long*))[0x55fc87a32dcd]sql/sql_parse.cc:4408(mysql_execute_command(THD*, bool))[0x55fc8770ea4a]sql/sql_parse.cc:8030(mysql_parse(THD*, char*, unsigned int, Parser_state*))[0x55fc8772841a]sql/sql_parse.cc:1898(dispatch_command(enum_server_command, THD*, char*, unsigned int, bool))[0x55fc876fe4c8]sql/sql_parse.cc:1404(do_command(THD*, bool))[0x55fc876fb1ec]sql/sql_connect.cc:1418(do_handle_one_connection(CONNECT*, bool))[0x55fc87b611fb]sql/sql_connect.cc:1314(handle_one_connection)[0x55fc87b60a87]perfschema/pfs.cc:2203(pfs_spawn_thread)[0x55fc8887f697]nptl/pthread_create.c:478(start_thread)[0x7f7c323b9609]x86_64/clone.S:97(__GI___clone)[0x7f7c31f8e293]Query (0x62b0000a82a8): UPDATE t1 SET a='2000-01-01 10:20:30'