DML on temporary table tries to append keys for provider

Bug #1112514 reported by Seppo Jaakola on 2013-02-01
This bug affects 2 people
Affects Status Importance Assigned to Milestone
MySQL patches by Codership
Seppo Jaakola
Seppo Jaakola
Percona XtraDB Cluster moved to
Fix Released

Bug Description

any update/delete/insert for temporary innodb table, will cause call for provider library append_key() call. The appended key values show as memory leak, and will be released only at server shutdown.

Changed in codership-mysql:
status: New → In Progress
importance: Undecided → High
assignee: nobody → Seppo Jaakola (seppo-jaakola)
milestone: none → 5.5.29-24.8
Mark Rose (markrose) wrote :

The bug is easy to reproduce. Here is a simplified version:

-- create source table and sample data
CREATE TABLE source (id BIGINT, data BIGINT, PRIMARY KEY(id, data), INDEX (data));
INSERT INTO source (id, data) VALUES (1, 1), (2, 2), (3, 2), (4, 2), (5, 3);

-- create temporary table and insert-select into it
-- this leaks
INSERT INTO temp (id, data) SELECT id, data FROM source WHERE data = 2;

Changed in percona-xtradb-cluster:
status: New → Confirmed
Seppo Jaakola (seppo-jaakola) wrote :

Fix was pushed in wsrep-23 in revision:
The fix avoids provider key append if affected table is temporary.

However, when testing with the fix build, the mysqld memory image keeps on growing after DML operations on temporary table, and these allocations do not seem to be released when the temporary table is dropped. This behavior is only with InnoDB temporary tables, MyISAM temporary tables behave as expected. It may be that InnoDB temporary table implementation has a memory leak problem, here is one potential bug tracker to follow:

Changed in percona-xtradb-cluster:
milestone: none → 5.5.29-23.7.2
importance: Undecided → High
status: Confirmed → Fix Committed


During this leak that you noticed with InnoDB temporary tables, did you see 'FLUSH TABLES' freeing any memory

I came across a similar bug here where file handles were being leaked. Was this the case there as well?

Changed in percona-xtradb-cluster:
status: Fix Committed → Fix Released


 I have reported a separate XtraDB bug here - to investigate this from that angle.

Alex Yurchenko (ayurchen) wrote :

fix released in 23.7.3

The fix for this issue is causing (check last few comments).

Percona now uses JIRA for bug reports so this bug report is migrated to:

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.