Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
13.2
-
Either a valgrind or ASAN builds on a linux machine
-
Can result in unexpected behaviour
Description
Memory leak of derived_handler when a multi-table UPDATE fails after derived-table prepare statement.
With a FederatedX table t2 pointing at a remote server, and federated_pushdown=1:
SET GLOBAL federated_pushdown=1; |
WITH cte1 AS (SELECT * FROM t2 WHERE t2.a < 5) |
UPDATE cte1 SET cte1.a = cte1.a * 2; |
Running it again with EXPLAIN in front also leaks, so each statement leaks one handler.
Both statements are in federated.federatedx_pushdown_upd_del (about lines 145-153). The leak shows up under valgrind.:
1,296 bytes in 2 blocks are definitely lost
|
at operator new(unsigned long) |
by TABLE_LIST::find_derived_handler(THD*) (sql_derived.cc:1751)
|
by mysql_derived_prepare(THD*, LEX*, TABLE_LIST*) (sql_derived.cc:949)
|
by mysql_derived_merge_for_insert(...) (sql_derived.cc:549)
|
by mysql_handle_derived(LEX*, unsigned int) (sql_derived.cc:158) |
by Multiupdate_prelocking_strategy::handle_end(THD*) (sql_update.cc:1688)
|
by open_tables(...)
|
by Sql_cmd_dml::prepare(THD*) (sql_select.cc:35879)
|
Note: This issue is found with MDEV-39226 (multi-table UPDATE/DELETE pushdown). But, it is technically independent of that change, since the leak path is in the derived-handler code.
Attachments
Issue Links
- relates to
-
MDEV-39226 Direct multi-table update/delete interface and FederatedX implementation
-
- Closed
-
