Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Duplicate
-
10.3.11, 10.3.28, 10.4.18, 10.5.9
-
CentOS 7.7, CentOS 7.9
Description
Running the attached query on the attached data set results in a signal 11 crash when "split_materialized=on" (default). split_materialized=off stops the crashing immediately.
When the query is run with split_materialized=off, and split_materialized is turned on again, the query sometimes runs once or twice without crashing, and then proceeds to crash as before. This behaviour is identical across all versions tested, implying some asynchronous process like flushing contributes to the crash.
Particularly noteworthy is that per the user this (theoretically non-updating) query causes index corruption that propagates to slaves with row-based replication.
Backtrace also attached. Note that the crash only happens with certain additional configurations. In the enclosed unencrypted test configuration (cs0280391-server.cnf), removing the persistent statistics section of the configuration stops the crash.
Attachments
Issue Links
- duplicates
-
MDEV-23723 Crash when test_if_skip_sort_order() is checked for derived table subject to split
- Closed
- relates to
-
MDEV-23192 Crash in row_search_mvcc() probably related to secondary index corruption
- Closed