Bug #83113 SIGKILL myself on DROP TABLE
Submitted: 23 Sep 2016 4:13 Modified: 14 Jul 2017 2:25
Reporter: Roel Van de Paar Email Updates:
Status: Verified Impact on me:
None 
Category:MySQL Server: DML Severity:S1 (Critical)
Version:5.1.67,8.0-dmr OS:Any
Assigned to: CPU Architecture:Any

[23 Sep 2016 4:13] Roel Van de Paar
Description:
Version: '8.0.0-dmr-debug'  socket: '/sda/MS130916-mysql-8.0.0-dmr-linux-x86_64-debug/socket.sock'  port: 15348  MySQL Community Server (GPL)
2016-09-23T03:52:00.282158Z 3 [Note] InnoDB: innodb_change_buffering_debug evict [page id: space=13, page number=29]
2016-09-23T03:52:00.282380Z 3 [Note] InnoDB: innodb_change_buffering_debug evict [page id: space=13, page number=22]
2016-09-23T03:52:00.282513Z 3 [Note] InnoDB: innodb_change_buffering_debug evict [page id: space=13, page number=44]
2016-09-23T03:52:00.317222Z 3 [Note] InnoDB: innodb_change_buffering_debug flush [page id: space=13, page number=29]
2016-09-23T03:52:00.345345Z 3 [Note] InnoDB: innodb_change_buffering_debug flush [page id: space=13, page number=29]
2016-09-23T03:52:00.345766Z 3 [Note] InnoDB: innodb_change_buffering_debug evict [page id: space=13, page number=25]
2016-09-23T03:52:00.368599Z 3 [Note] InnoDB: innodb_change_buffering_debug flush [page id: space=13, page number=29]
2016-09-23T03:52:00.406373Z 3 [Note] InnoDB: innodb_change_buffering_debug flush [page id: space=13, page number=29]
2016-09-23T03:52:00.432037Z 3 [Note] InnoDB: innodb_change_buffering_debug flush [page id: space=13, page number=29]
2016-09-23T03:52:00.464775Z 0 [Note] InnoDB: innodb_change_buffering_debug flush [page id: space=13, page number=29]
2016-09-23T03:52:00.502248Z 0 [Note] InnoDB: innodb_change_buffering_debug flush [page id: space=13, page number=24]
2016-09-23T03:52:00.524148Z 0 [Note] InnoDB: innodb_change_buffering_debug flush [page id: space=13, page number=24]
2016-09-23T03:52:00.558328Z 0 [Note] InnoDB: innodb_change_buffering_debug flush [page id: space=13, page number=24]
SIGKILL myself

How to repeat:
# MS130916-mysql-8.0.0-dmr-linux-x86_64-debug

DROP DATABASE test;
SET @start_global_value=@@global.tmp_table_size;
SET @@global.innodb_change_buffering_debug=@start_global_value;
drop table mysql.general_log;
select 1;  # Shows server is gone
[23 Sep 2016 4:34] Roel Van de Paar
May be related to bug #83113
[23 Sep 2016 5:02] Roel Van de Paar
May be related to bug #83119
[23 Sep 2016 5:02] Roel Van de Paar
May be related to bug #83116
[23 Sep 2016 5:07] MySQL Verification Team
Hello Roel,

Thank you for the report and test case.
Observed that 8.0 debug build is affected.

Thanks,
Umesh
[23 Sep 2016 9:41] Marko Mäkelä
Posted by developer:
 
Is this even a bug? The debug parameter innodb_change_buffering_debug=2 is designed to kill the server when a change buffer merge is about to occur. The value 2 was introduced in the Bug#14636528 fix by me.
[23 Sep 2016 9:45] Marko Mäkelä
The variable value innodb_change_buffering_debug=2 was introduced for crash injection testing in the fix of
Bug#66819 InnoDB change buffering is not entirely crash-safe
[23 Sep 2016 10:31] Marko Mäkelä
Posted by developer:
 
It may be worth noting that because the Global Data Dictionary tables in MySQL 8.0 define a large number of non-unique secondary indexes, any DDL operations could exercise the InnoDB change buffer. It could make sense to disable change buffering for the data dictionary tables. (Change buffering is effectively disabled for the InnoDB-internal data dictionary tables, because there are no non-unique secondary indexes defined on the SYS_* tables.)

Note that DDL operations are not atomic or crash-safe in MySQL 8.0.0. There still exist two persistent data dictionaries: the Global Data Dictionary (which replaced *.frm files) and the InnoDB data dictionary. If you trigger a crash during DDL, the table may become inaccessible as the two data dictionaries can easily get out of sync with each other. In the worst case (a crash during ALTER TABLE...ALGORITHM=INPLACE), the table would exist in both dictionaries, but with a different schema.
[30 Sep 2016 19:41] James Day
Disabling change buffering for the DD seems like a good idea, given that we have innodb_force_recovery = 4 and above that are supposed to disable change buffer merging work, which would not be good to just skip on dictionary operations. Dictionary is also likely to be very well cached in the buffer pool so the performance cost would probably be low. And of course good caching implies little benefit to change buffer support anyway.
[9 Jan 2017 1:43] Roel Van de Paar
> Note that DDL operations are not atomic or crash-safe in MySQL 8.0.0.

What is the plan for GA in this area?
[14 Jul 2017 2:24] Roel Van de Paar
Any updates please?
[14 Jul 2017 2:25] Roel Van de Paar
The version on this bug was set to 5.1.67 - ?
[14 Jul 2017 2:25] Roel Van de Paar
.