The SELECT with the INNER JOIN is executed with one of the two tables being
optimized as a constant table, which is pre-read. Spider nevertheless attempts
to push down the join to the data node. The crash occurs because the constant
table is excluded from the optimized query that Spider attempts to push down.
In order for Spider to be able to push down a join, the following conditions
need to be met:
- All of the tables involved in the join need to be included in the optimized
query that Spider pushes down. When any of the tables involved in the join
is a constant table, it is excluded from the optimized query that Spider
attempts to push down.
- All fields involved in the query need to be members of tables included in the
optimized query.
I fixed the problem by preventing Spider from pushing down queries that include
a field that is not a member of a table included in the optimized query. This
solution fixes the reported problem and also fixes other potential problems.
Author:
Jacob Mathew.
Reviewer:
Kentoku Shiba.
Cherry-Picked:
Commit 4885baf on branch bb-10.3-MDEV-16889
MDEV-16250: Spider system tables are MyISAM and needs repair after a crash
During a server restart that follows a server crash, there may be error
messages that indicate that certain system tables are marked as crashed and
may be corrupted. Upon checking the system tables that are marked as crashed,
it may be found that there is no corruption that needs repair. However, the
error messages that are issued imply that the user needs to nevertheless
manually repair the system tables that were marked as crashed. These issues
have been moved to a separate bug MDEV-17068.
MDEV-16250 addresses the work to make the Spider system tables crash safe.
This work involves the following changes in 10.4:
- Changes to the install_spider.sql script to change the storage engine for
the Spider system tables to Aria. This is implemented in such a way as to
allow the script to be run repeatedly without any harm or errors.
- Changes to the init_spider.inc script that is run during initialization of
every test in the Spider test suites. This script now uses the Aria
storage engine for the Spider system tables in MariaDB Server 10.4 and
later releases.
- Added a test to the Spider test suite to display the storage engine of each
Spider system table, to verify that the correct storage engine is used.
Author:
Jacob Mathew.
Reviewer:
Kentoku Shiba.
Merged:
Commit 73fac2a from branch bb-10.4-MDEV-16250
MDEV-17068 mysql system table is marked as crashed and should be repaired after the server crashes or is killed
- Changed ERROR to WARNING for MyISAM/Aria message
that are warnings in the check utilities.
This affects for example "client is using or
hasn't closed the table properly".
- Print "Table is fixed" if check succeded in
fixing the table.
MDEV-16250: Spider system tables are MyISAM and needs repair after a crash
During a server restart that follows a server crash, there may be error
messages that indicate that certain system tables are marked as crashed and
may be corrupted. Upon checking the system tables that are marked as crashed,
it may be found that there is no corruption that needs repair. However, the
error messages that are issued imply that the user needs to nevertheless
manually repair the system tables that were marked as crashed. These issues
have been moved to a separate bug MDEV-17068.
MDEV-16250 addresses the work to make the Spider system tables crash safe.
This work involves the following changes in 10.4:
- Changes to the install_spider.sql script to change the storage engine for
the Spider system tables to Aria. This is implemented in such a way as to
allow the script to be run repeatedly without any harm or errors.
- Changes to the init_spider.inc script that is run during initialization of
every test in the Spider test suites. This script now uses the Aria
storage engine for the Spider system tables in MariaDB Server 10.4 and
later releases.
- Added a test to the Spider test suite to display the storage engine of each
Spider system table, to verify that the correct storage engine is used.
Moved the checks for arguments validation of Item_name_const from the constructor
to Create_func_name_const::create_2_arg
Also reverted the fix bf1c53e9be84437ada32393bb7b4a8ff06dbf369
MDEV-16986 Unitialized mutex, SIGSEGV and assorted assertion failures in Aria code
The problem was that when a mysql.proc table was
opened for reading it was added to the current Aria
transaction context but never properly deleted from
it. Normally this isn't a problem, except if the
mysql.proc table is closed before the transaction
ended, which happened in this test case.
Fixed by removing mysql.proc from the transaction
context before closing the table.
