MDEV-13779 InnoDB fails to shut down purge workers, causing hang
srv_purge_coordinator_thread(): Wait for all purge worker threads
to actually exit. An analysis of a core dump of a hung 10.3 server
revealed that one srv_worker_thread did not exit, even though the
purge coordinator had exited. This caused kill_server_thread and
mysqld_main to wait indefinitely. The main InnoDB shutdown was
never called, because unireg_end() was never called.
Imported the following test case from mysql to MariaDB
1) innodb.alter_kill
2) innodb.alter_foreign_crash
3) innodb.alter_rename_files
4) innodb.analyze_table
5) Appended the case in innodb-online-alter-gis
BUG#22385442 - INNODB: DIFFICULT TO FIND FREE BLOCKS IN THE BUFFER POOL
Problem:
We keep pinning pages in dict_stats_analyze_index_below_cur(),
but doesn't release these pages. When we have a relative small
buffer pool size, and big innodb_stats_persistent_sample_pages,
there will be no free pages for use.
Solution:
Use a separate mtr in dict_stats_analyze_index_below_cur(),
and commit mtr before return.
Reviewed-by: Jimmy Yang <email address hidden>
RB: 11362
0ba299d...
by
=?utf-8?b?TWFya28gTcOka2Vsw6Q=?= <email address hidden>
Bug#21628087 innodb_log_checkpoint_now not fully compatible with WL#7142
In debug builds of MySQL, there is an configuration variable
that allows an InnoDB log checkpoint to be initiated:
SET GLOBAL innodb_log_checkpoint_now=ON;
Setting this variable while a table-rebuilding ALTER TABLE is executing
may result in an infinite loop.
checkpoint_now_set(): Account for log_sys->append_on_checkpoint->size().
Note that this function contains race conditions, because it is accessing
fields of log_sys without holding log_sys->mutex. We think that this is
acceptable, because this variable only exists for debugging purposes, in
debug builds of MySQL.
