File: innodb_bug12429573.test

package info (click to toggle)
mysql-8.0 8.0.43-3
  • links: PTS, VCS
  • area: main
  • in suites: sid
  • size: 1,273,924 kB
  • sloc: cpp: 4,684,605; ansic: 412,450; pascal: 108,398; java: 83,641; perl: 30,221; cs: 27,067; sql: 26,594; sh: 24,181; python: 21,816; yacc: 17,169; php: 11,522; xml: 7,388; javascript: 7,076; makefile: 2,194; lex: 1,075; awk: 670; asm: 520; objc: 183; ruby: 97; lisp: 86
file content (40 lines) | stat: -rw-r--r-- 1,360 bytes parent folder | download
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
#
# Bug#12429573 TIMESTAMP COLUMN OF INNODB.INDEX_STATS ARE NOT UPDATED
# WHEN RE-RUNNING ANALYZE
#


CREATE TABLE bug12429573 (i INTEGER PRIMARY KEY, j INTEGER, KEY(j))
ENGINE=INNODB STATS_PERSISTENT=1;

ANALYZE TABLE bug12429573;

# Cannot check the exact timestamp here because it is always different
# but at least check that both timestamps in innodb_table_stats and in
# innodb_index_stats have been updated to the same value. If the bug is
# present this check will fail.

SELECT last_update FROM mysql.innodb_index_stats WHERE
table_name = 'bug12429573' AND
last_update NOT IN
(SELECT last_update FROM mysql.innodb_table_stats
 WHERE table_name = 'bug12429573');

# The first ANALYZE would insert timestamp e.g. 17:23:39 in both
# innodb_table_stats and innodb_index_stats. The bug is that the second
# ANALYZE only updates the timestamp in innodb_table_stats. In order to
# check if the timestamp in innodb_index_stats has really been updated we
# need it to be different from the previous one (17:23:39) with at least
# one second.
-- sleep 1

ANALYZE TABLE bug12429573;

# If the bug is present we get the timestamps different here.
SELECT last_update FROM mysql.innodb_index_stats WHERE
table_name = 'bug12429573' AND
last_update NOT IN
(SELECT last_update FROM mysql.innodb_table_stats
 WHERE table_name = 'bug12429573');

DROP TABLE bug12429573;