Server crashed during a sort order optimization
of a dependent subquery:
SELECT
(SELECT t1.a FROM t1, t2
WHERE t1.a = t2.b AND t2.a = t3.c
ORDER BY t1.a)
FROM t3;
Bitmap of tables, that the reference to outer table
column uses, in addition to the regular table bit
has the OUTER_REF_TABLE_BIT bit set.
The only_eq_ref_tables function traverses this map
bit by bit simultaneously with join->map2table list.
Obviously join->map2table never contains an entry
for the OUTER_REF_TABLE_BIT pseudo-table, so the
server crashed there.
The only_eq_ref_tables function has been modified
to traverse regular table bits only like the
update_depend_map function (resetting of the
OUTER_REF_TABLE_BIT there is enough, but
resetting of the whole set of PSEUDO_TABLE_BITS
is used there for sure).
mysql-test/r/order_by.result:
Added test case for bug #39844.
mysql-test/t/order_by.test:
Added test case for bug #39844.
sql/sql_select.cc:
Bug #39844: Query Crash Mysql Server 5.0.67
The only_eq_ref_tables function has been modified
to traverse regular table bits only like the
update_depend_map function (resetting of the
OUTER_REF_TABLE_BIT there is enough, but
resetting of the whole set of PSEUDO_TABLE_BITS
is used there for sure).
Added the missing DROP TABLE
mysql-test/r/windows.result:
Bug #39958: added the missing DROP TABLE
mysql-test/t/windows.test:
Bug #39958: added the missing DROP TABLE
The problem is that the offset argument of the limit clause
might be truncated on a 32-bits server built without big
tables support. The truncation was happening because the
original 64-bits long argument was being cast to a 32-bits
(ha_rows) offset counter.
The solution is to check if the conversing resulted in value
truncation and if so, the offset is set to the maximum possible
value that can fit on the type.
mysql-test/r/limit.result:
Add test case result for Bug#37075
mysql-test/t/limit.test:
Add test case for Bug#37075
sql/sql_lex.cc:
Check for truncation of the offset value. If value was
truncated, set to the maximum possible value.
If delayed insert fails to upgrade the lock it was not
freeing the temporary memory storage used to keep
newly constructed blob values in memory.
Fixed by iterating over the remaining rows in the delayed
insert rowset and freeing the blob storage for each row.
No test suite because it involves concurrent delayed inserts
on a table and cannot easily be made deterministic.
Added a correct valgrind suppression for Fedora 9.
mysql-test/valgrind.supp:
Added a vagrind suppression for Fedora 9
sql/sql_insert.cc:
Bug #38693: free the blobs temp storage on error.
Don't fsync() index file when closing Maria table if not transactional.
mysql-test/suite/maria/r/maria.result:
piece moved
mysql-test/suite/maria/r/maria_partition.result:
result
mysql-test/suite/maria/t/maria.test:
- reset default storage engine at end of test, not in the middle
- move piece which requires partitioning, to maria_partition.test, otherwise test fails
on builds without partitioning compiled in
mysql-test/suite/maria/t/maria_partition.test:
new test for those Maria bugs which are specific of partitioning
mysys/my_uuid.c:
compiler warning fix (fix imported from latest 5.1-main)
storage/maria/ma_close.c:
don't fsync() index file when closing table if not transactional
(same test as in _ma_once_end_block_record() when fsync-ing data file)
storage/maria/ma_create.c:
compiler warning fix (char* assigned to uchar*)
storage/maria/ma_loghandler.c:
compiler warning fix (char* assigned to uchar*)
Fixed that mysql-test-run --skip-from starts from the given test
mysql-test/lib/mtr_cases.pl:
Moved testing of $opt_start_from to mysql-test-run.pl because tests are now run per suite and the old way would rerun not wanted tests
mysql-test/mysql-test-run.pl:
Fixed that mysql-test-run --skip-from starts from the given test
The problem is that field names constructed due to wild-card
expansion done inside a stored procedure could point to freed
memory if the expansion was performed after the first call to
the stored procedure.
The problem was solved by patch for Bug#38691. The solution
was to allocate the database, table and field names in the
in the statement memory instead of table memory.
mysql-test/r/sp.result:
Add test case result for Bug#38823
mysql-test/t/sp.test:
Add test case for Bug#38823
sql/item.cc:
Remark that this also impacts wildcard expansion inside SPs.
- The problem was that we didn't inform the handler that we are going to close tables that are locked and may have (at least in Maria) be part of an active transaction.
Fix for Bug#39227 Maria: crash with ALTER TABLE PARTITION
Fix for Bug #39987 main.partition_not_windows fails under debug build
Fixed some compiler errors & warnings found by pushbuild
include/my_base.h:
Added HA_EXTRA_PREPARE_FOR_FORCED_CLOSE for signaling the handler that the file will be forced closed
include/my_global.h:
Removed 'register' from 'swap_variables' as this gives a warnings when the variables are structs. Compilers should also now be smart enough to figure out this themselves
mysql-test/r/subselect_debug.result:
Reset value of the debug variable; Without setting this the subselect_innodb test will fail when run after this one
mysql-test/suite/maria/r/maria.result:
Merged test with myisam.test
Added tests for new fixed bugs
mysql-test/suite/maria/t/maria.test:
Merged test with myisam.test
Added tests for new fixed bugs
mysql-test/t/subselect_debug.test:
Reset value of the debug variable; Without setting this the subselect_innodb test will fail when run after this one
mysys/my_uuid.c:
Fixed compiler error on windows
sql/ha_partition.cc:
Added support for the new extra flag: HA_EXTRA_PREPARE_FOR_FORCED_CLOSE (Bug #39226)
Ensure that we call extra() for HA_EXTRA_PREPARE_FOR_DROP (Bug#39227)
sql/mysqld.cc:
Fix for Bug #39987 main.partition_not_windows fails under debug build
The problem was that when compiling for purify/valgrind realpath() is not used, which causes test_if_data_home_dir to fail when it shouldn't
sql/sql_base.cc:
Call HA_EXTRA_PREPARE_FOR_FORCED_CLOSE for tables that are locked but we are going to force close without doing a commit
sql/sql_parse.cc:
More DBUG_PRINT. Fixed comments
storage/maria/ma_extra.c:
If HA_EXTRA_PREPARE_FOR_FORCED_CLOSE is called and the table is part of a transaction, remove the table from beeing part of a transaction.
This is safe as this is only used as part of flush tables or when the table is not part of a transaction
storage/myisam/mi_open.c:
Indentation fix
unittest/mysys/waiting_threads-t.c:
Remove not needed 'volatile' to get rid of compiler warnings on windows
on non-partitioned table
Problem was that partitioning specific commands was accepted
for non partitioned tables and treated like
ANALYZE/CHECK/OPTIMIZE/REPAIR TABLE, after bug-20129 was fixed,
which changed the code path from mysql_alter_table to
mysql_admin_table.
Solution was to check if the table was partitioned before
trying to execute the admin command
mysql-test/r/partition_mgm_err.result:
Bug#39434: ALTER TABLE CHECK/OPTIMIZE/ANALYZE PARTITION work
on non-partitioned table
Updated test result
mysql-test/t/partition_mgm_err.test:
Bug#39434: ALTER TABLE CHECK/OPTIMIZE/ANALYZE PARTITION work
on non-partitioned table
Updated test case
sql/ha_partition.cc:
Bug#39434: ALTER TABLE CHECK/OPTIMIZE/ANALYZE PARTITION work
on non-partitioned table
Simplified the code by using ALTER_ADMIN_PARTITION for all
commands that go through mysql_admin_tables and is set
for partitioning specific commands that.
sql/ha_partition.h:
Bug#39434: ALTER TABLE CHECK/OPTIMIZE/ANALYZE PARTITION work
on non-partitioned table
Simplified the code by using ALTER_ADMIN_PARTITION for all
commands that go through mysql_admin_tables and is set
for partitioning specific commands that.
sql/sql_lex.h:
Bug#39434: ALTER TABLE CHECK/OPTIMIZE/ANALYZE PARTITION work
on non-partitioned table
Simplified the code by using ALTER_ADMIN_PARTITION for all
commands that go through mysql_admin_tables and is set
for partitioning specific commands that.
Removed ALTER_ANALYZE/CHECK/OPTIMIZE/REPAIR_PARTITION and
added ALTER_ADMIN_PARTITION instead.
sql/sql_partition.cc:
Bug#39434: ALTER TABLE CHECK/OPTIMIZE/ANALYZE PARTITION work
on non-partitioned table
Simplified the code by using ALTER_ADMIN_PARTITION for all
commands that go through mysql_admin_tables and is set
for partitioning specific commands that.
Removed ALTER_ANALYZE/CHECK/OPTIMIZE/REPAIR_PARTITION and
added ALTER_ADMIN_PARTITION instead.
sql/sql_table.cc:
Bug#39434: ALTER TABLE CHECK/OPTIMIZE/ANALYZE PARTITION work
on non-partitioned table
Give error and return if trying partitioning admin command
on non partitioned table.
Simplified the code by using ALTER_ADMIN_PARTITION for all
commands that go through mysql_admin_tables and is set
for partitioning specific commands that.
Removed ALTER_ANALYZE/CHECK/OPTIMIZE/REPAIR_PARTITION and
added ALTER_ADMIN_PARTITION instead.
sql/sql_yacc.yy:
Bug#39434: ALTER TABLE CHECK/OPTIMIZE/ANALYZE PARTITION work
on non-partitioned table
Simplified the code by using ALTER_ADMIN_PARTITION for all
commands that go through mysql_admin_tables and is set
for partitioning specific commands that.
Removed ALTER_ANALYZE/CHECK/OPTIMIZE/REPAIR_PARTITION and
added ALTER_ADMIN_PARTITION instead.
Select with a "NULL NOT IN" condition containing complex
subselect from the same table as in the outer select failed
with an assertion.
The failure was caused by a concatenation of circumstances:
1) an inner select was optimized by make_join_statistics to use
the QUICK_RANGE_SELECT access method (that implies an index
scan of the table);
2) a subselect was independent (constant) from the outer select;
3) a condition was pushed down into inner select.
During the evaluation of a constant IN expression an optimizer
temporary changed the access method from index scan to table
scan, but an engine handler was already initialized for index
access by make_join_statistics. That caused an assertion.
Unnecessary index initialization has been removed from
the QUICK_RANGE_SELECT::init method (QUICK_RANGE_SELECT::reset
reinvokes this initialization).
mysql-test/r/subselect3.result:
Added test case for bug #37894.
mysql-test/t/subselect3.test:
Added test case for bug #37894.
sql/opt_range.cc:
Bug #37894: Assertion in init_read_record_seq in handler.h line 1444
Unnecessary index initialization has been removed from
the QUICK_RANGE_SELECT::init method (QUICK_RANGE_SELECT::reset
reinvokes this initialization).
with COALESCE and JOIN
The server returned to a client the VARBINARY column type
instead of the DATE type for a result of the COALESCE,
IFNULL, IF, CASE, GREATEST or LEAST functions if that result
was filesorted in an anonymous temporary table during
the query execution.
For example:
SELECT COALESCE(t1.date1, t2.date2) AS result
FROM t1 JOIN t2 ON t1.id = t2.id ORDER BY result;
To create a column of various date/time types in a
temporary table the create_tmp_field_from_item() function
uses the Item::tmp_table_field_from_field_type() method
call. However, fields of the MYSQL_TYPE_NEWDATE type were
missed there, and the VARBINARY columns were created
by default.
Necessary condition has been added.
mysql-test/r/metadata.result:
Added test case for bug #39283.
mysql-test/t/metadata.test:
Added test case for bug #39283.
sql/sql_select.cc:
Bug #39283: Date returned as VARBINARY to client for queries
with COALESCE and JOIN
To create a column of various date/time types in a
temporary table the create_tmp_field_from_item() function
uses the Item::tmp_table_field_from_field_type() method
call. However, fields of the MYSQL_TYPE_NEWDATE type were
missed there, and the VARBINARY columns were created
by default.
Necessary condition has been added.
index column
There was actually two problems
1) when clustered pk, order by non pk index should also
compare with pk as last resort to differ keys from each
other
2) bug in the index search handling in ha_partition (was
found when extending the test case
Solution to 1 was to include the pk in key compare if
clustered pk and search on other index.
Solution for 2 was to remove the optimization from
ordered scan to unordered scan if clustered pk.
mysql-test/r/partition_innodb.result:
Bug#37721: ORDER BY when WHERE contains non-partitioned
index column
updated test result.
mysql-test/t/partition_innodb.test:
Bug#37721: ORDER BY when WHERE contains non-partitioned
index column
Added test case for bug verification.
sql/ha_partition.cc:
Bug#37721: ORDER BY when WHERE contains non-partitioned
index column
using m_curr_key_info with both given index and PK
if clustered PK.
Also including PK in read_set.
Added debug prints for easier verification.
sql/ha_partition.h:
Bug#37721: ORDER BY when WHERE contains non-partitioned
index column
Changed m_curr_key_info to a null terminated array
with max 2 keys and a terminating null.
For use with key_rec_cmp with both given index and PK.
sql/key.cc:
Bug#37721: ORDER BY when WHERE contains non-partitioned
index column
added handling of a null terminated array of keys for
use in compare.
It was a forgotten rw_unlock(), due to the deadlock detector feature (so bug was only in 5.1-maria, not
6.0-maria).
mysql-test/suite/maria/r/maria3.result:
result, all fine
mysql-test/suite/maria/t/maria3.test:
Test of BUG#39697: two scenarios (transactional tables, and non-transactional table but dynamic row format so still taking the rwlock) where the hang happened.
t2 added by this test was masked by a temporary table created earlier in the test, which we forgot to drop.
storage/maria/ha_maria.cc:
use new macro
storage/maria/ma_blockrec.c:
use new macro
storage/maria/ma_commit.c:
use new macro
storage/maria/ma_init.c:
putting address of dummy_transaction_object in --debug trace can be useful
storage/maria/ma_open.c:
use new macro
storage/maria/ma_write.c:
if local_lock_tree is true, we have acquired keyinfo->root_lock so need to release it before "goto err".
A pair of assertions so that our usage of TrIDs is kept sensible.
storage/maria/maria_def.h:
A macro so that changes of MARIA_HA::trn can be tracked with --debug. It helped to understand in what cases,
in maria_write(), we could have !(info->dup_key_trid == info->trn->trid) && !share->now_transactional
(answer: ALTER TABLE adding UNIQUE index on transactional table).
derived table cause crash
When a multi-UPDATE command fails to lock some table, and
subsequently succeeds, the tables need to be reopened if
they were altered. But the reopening procedure failed for
derived tables.
Extra cleanup has been added.
mysql-test/r/lock_multi.result:
Added test case for bug #38499.
mysql-test/t/lock_multi.test:
Added test case for bug #38499.
sql/sql_union.cc:
Bug#38499: flush tables and multitable table update with
derived table cause crash
Obsolete assertion has been removed.
sql/sql_update.cc:
Bug#38499: flush tables and multitable table update with
derived table cause crash
Extra cleanup for derived tables has been added:
1) unit.cleanup(),
2) unit->reinit_exec_mechanism().
TRIGGERS.SQL_MODE, EVENTS.SQL_MODE, TRIGGERS.DEFINER:
field type is changed to VARCHAR.
mysql-test/r/information_schema.result:
result fix
mysql-test/r/show_check.result:
result fix
mysql-test/suite/funcs_1/r/is_columns_is.result:
result fix
mysql-test/suite/funcs_1/r/is_events.result:
result fix
mysql-test/suite/funcs_1/r/is_triggers.result:
result fix
sql/sql_show.cc:
TRIGGERS.SQL_MODE, EVENTS.SQL_MODE, TRIGGERS.DEFINER:
field type is changed to VARCHAR.
The problem was that PACK_KEYS and MAX_ROWS clause in ALTER TABLE did not trigger
table reconstruction.
The fix is to rebuild a table if PACK_KEYS or MAX_ROWS are specified.
mysql-test/r/alter_table.result:
test result
mysql-test/t/alter_table.test:
test case
sql/sql_table.cc:
The problem was that PACK_KEYS and MAX_ROWS clause in ALTER TABLE did not trigger
table reconstruction.
The fix is to rebuild a table if PACK_KEYS or MAX_ROWS are specified.
Hide "Table doesn't exist" errors if the table belongs to a merge table.
mysql-test/r/merge.result:
result fix
mysql-test/t/merge.test:
test case
sql/sql_base.cc:
Hide "Table doesn't exist" errors if the table belongs to a merge table.
The problem: table_open_method is not calculated properly if '*' is used in 'select'
The fix: added table_open_method calculation for such case
mysql-test/r/information_schema.result:
test result
mysql-test/t/information_schema.test:
test case
sql/sql_show.cc:
The problem: table_open_method is not calculated properly if '*' is used in 'select'
The fix: added table_open_method calculation for such case
When running Stored Routines the Status Variable "Questions" was wrongly
incremented. According to the manual it should contain the "number of
statements that clients have sent to the server"
Introduced a new status variable 'questions' to replace the query_id
variable which currently corresponds badly with the number of statements
sent by the client.
The new behavior is ment to be backward compatible with 4.0 and at the
same time work with new features in a similar way.
This is a backport from 6.0
mysql-test/r/status2.result:
Added test case
mysql-test/t/status2.test:
Added test case
sql/mysqld.cc:
Introduced a new status variable 'questions' to replace the query_id
variable which currently corresponds badly with the number of statements
sent by the client.
sql/sql_class.h:
Introduced a new status variable 'questions' to replace the query_id
variable which currently corresponds badly with the number of statements
sent by the client.
sql/sql_parse.cc:
To be backward compatible with 4.0 and at the same time extend the
interpretation of the Question variable, it should be increased on
all COM-commands but COM_STATISTICS, COM_PING, COM_STMT_PREPARE,
COM_STMT_CLOSE and COM_STMT_RESET.
Since COM_QUERY can process multiple statements, there has to be an
extra increase there as well.
sql/sql_show.cc:
Removed deprecated SHOW_QUESTION status code.
sql/structs.h:
Removed deprecated SHOW_QUESTION status code.
The code to get read the value of a system variable was extracting its value
on PREPARE stage and was substituting the value (as a constant) into the parse tree.
Note that this must be a reversible transformation, i.e. it must be reversed before
each re-execution.
Unfortunately this cannot be reliably done using the current code, because there are
other non-reversible source tree transformations that can interfere with this
reversible transformation.
Fixed by not resolving the value at PREPARE, but at EXECUTE (as the rest of the
functions operate). Added a cache of the value (so that it's constant throughout
the execution of the query). Note that the cache also caches NULL values.
Updated an obsolete related test suite (variables-big) and the code to test the
result type of system variables (as per bug 74).
mysql-test/extra/rpl_tests/rpl_insert_id.test:
Bug #32124: removed ambiguous testcase
mysql-test/r/innodb_data_home_dir_basic.result:
Bug #32124: fixed wrong test case
mysql-test/r/innodb_flush_method_basic.result:
Bug #32124: fixed wrong test case
mysql-test/r/ps_11bugs.result:
Bug #32124: test case
mysql-test/r/ssl_capath_basic.result:
Bug #32124: fixed wrong test case
mysql-test/r/ssl_cipher_basic.result:
Bug #32124: fixed wrong test case
mysql-test/r/variables.result:
Bug #32124: system vars are shown as such in EXPLAIN EXTENDED, not as constants.
mysql-test/suite/rpl/r/rpl_insert_id.result:
Bug #32124: removed ambiguous testcase
mysql-test/t/ps_11bugs.test:
Bug #32124: test case
sql/item.cc:
Bug #32124: placed the code to convert string to longlong or double
to a function (so that it can be reused)
sql/item.h:
Bug #32124: placed the code to convert string to longlong or double
to a function (so that it can be reused)
sql/item_func.cc:
Bug #32124: moved the evaluation of system variables at runtime (val_xxx).
sql/item_func.h:
Bug #32124: moved the evaluation of system variables at runtime (val_xxx).
sql/set_var.cc:
Bug #32124: removed the code that calculated the system variable's value
at PREPARE
sql/set_var.h:
Bug #32124: removed the code that calculated the system variable's value
at PREPARE
tests/mysql_client_test.c:
Bug #32124 : removed the reading of the system variable, because its max
length is depended on the system charset and client charset and can't be
easily calculated.
The failure was caused by executing a CREATE-SELECT statement that creates a
table in another database than the current one. In row-based logging, the
CREATE statement was written to the binary log without the database, hence
creating the table in the wrong database, causing the following inserts to
fail since the table didn't exist in the given database.
Fixed the bug by adding a parameter to store_create_info() that will make
the function print the database name before the table name and used that
in the calls that write the CREATE statement to the binary log. The database
name is only printed if it is different than the currently selected database.
The output of SHOW CREATE TABLE has not changed and is still printed without
the database name.
mysql-test/suite/rpl/t/rpl_row_create_table.test:
Added test to check that CREATE-SELECT into another database than the
current one replicates.
sql/sql_insert.cc:
Adding parameter to calls to store_create_info().
sql/sql_show.cc:
Adding parameter to calls to store_create_info().
Extending store_create_info() with parameter 'show_database' that will cause
the database to be written before the table name.
sql/sql_show.h:
Adding parameter to call to store_create_info() to tell if the database should be shown or not.
sql/sql_table.cc:
Adding parameter to calls to store_create_info().
``FLUSH TABLES WITH READ LOCK''
Concurrent execution of 1) multitable update with a
NATURAL/USING join and 2) a such query as "FLUSH TABLES
WITH READ LOCK" or "ALTER TABLE" of updating table led
to a server crash.
The mysql_multi_update_prepare() function call is optimized
to lock updating tables only, so it postpones locking to
the last, and if locking fails, it does cleanup of modified
syntax structures and repeats a query analysis. However,
that cleanup procedure was incomplete for NATURAL/USING join
syntax data: 1) some Field_item items pointed into freed
table structures, and 2) the TABLE_LIST::join_columns fields
was not reset.
Major change:
short-living Field *Natural_join_column::table_field has
been replaced with long-living Item*.
mysql-test/r/lock_multi.result:
Added test case for bug #38691.
mysql-test/t/lock_multi.test:
Added test case for bug #38691.
sql/item.cc:
Bug #38691: segfault/abort in ``UPDATE ...JOIN'' while
``FLUSH TABLES WITH READ LOCK''
The Item_field constructor has been modified to allocate
and copy original database/table/field names always (not
during PS preparation/1st execution only), because
an initialization of Item_field items with a pointer to
short-living Field structures is a common practice.
sql/sql_base.cc:
Bug #38691: segfault/abort in ``UPDATE ...JOIN'' while
``FLUSH TABLES WITH READ LOCK''
1) Type adjustment for Natural_join_column::table_field
(Field to Item_field);
2) The setup_natural_join_row_types function has been
updated to take into account new
first_natural_join_processing flag to skip unnecessary
reinitialization of Natural_join_column::join_columns
during table reopening after lock_tables() failure
(like the 'first_execution' flag for PS).
sql/sql_lex.cc:
Bug #38691: segfault/abort in ``UPDATE ...JOIN'' while
``FLUSH TABLES WITH READ LOCK''
Initialization of the new
st_select_lex::first_natural_join_processing flag has
been added.
sql/sql_lex.h:
Bug #38691: segfault/abort in ``UPDATE ...JOIN'' while
``FLUSH TABLES WITH READ LOCK''
The st_select_lex::first_natural_join_processing flag
has been added to skip unnecessary rebuilding of
NATURAL/USING JOIN structures during table reopening
after lock_tables failure.
sql/sql_update.cc:
Bug #38691: segfault/abort in ``UPDATE ...JOIN'' while
``FLUSH TABLES WITH READ LOCK''
Extra cleanup calls have been added to reset
Natural_join_column::table_field items.
sql/table.cc:
Bug #38691: segfault/abort in ``UPDATE ...JOIN'' while
``FLUSH TABLES WITH READ LOCK''
Type adjustment for Natural_join_column::table_field
(Field to Item_field).
sql/table.h:
Bug #38691: segfault/abort in ``UPDATE ...JOIN'' while
``FLUSH TABLES WITH READ LOCK''
Type of the Natural_join_column::table_field field has
been changed from Field that points into short-living
TABLE memory to long-living Item_field that can be
linked to (fixed) reopened table.
ha_statistic_increment for rpl_temporary
Problem: in some cases master send a special event to reconnecting
slave to keep slave's temporary tables (see #17284) and they still
have references to the "old" SQL slave thread and use them to access
thread's data.
Fix: set temporary tables thread references to the actual SQL slave
thread in such cases.
mysql-test/suite/rpl/t/disabled.def:
Fix for bug#38269: pushbuild gives valgrind error in
ha_statistic_increment for rpl_temporary
- rpl_temporary test enabled.
sql/log_event.cc:
Fix for bug#38269: pushbuild gives valgrind error in
ha_statistic_increment for rpl_temporary
- if we keep slave's temporary tables after reconnect,
set their thread pointers (->in_use) to the current SQL thread.
