Bug #19623 UniqueHashIndexes resource leak
Submitted: 8 May 2006 20:50 Modified: 31 May 2006 5:35
Reporter: Hartmut Holzgraefe Email Updates:
Status: Closed Impact on me:
Category:MySQL Cluster: Cluster (NDB) storage engine Severity:S2 (Serious)
Version:4.1, 5.0, 5.1 OS:Linux (linux)
Assigned to: Martin Skold CPU Architecture:Any

[8 May 2006 20:50] Hartmut Holzgraefe
Consider a cluster table of the following form:

CREATE TABLE t_counter_ (

this table should use one table entry, two orderedIndex entries 
(one for the primary key and one for the secondary index) and
one uniqueHashIndex for the secondary key.

So with the defaults of MaxNoOfTables=128, MaxNoOfOrderedIndexes=128,
MaxNoOfUniqueIndexes=64 it should be possible to create 64 tables 
like this on a fresh cluster setup before running out of index resources.

But it actually fails on table instance #16 already. When changing only 
MaxNoOfUniqueIndexes from 64 to 128 i can create 31 tables instead ...

A quick calculation shows that 15 tables take 

  15 *(1 tables + 2 ordered indexes + 1 hash index) = 60 'tabular objects'

for 16 tables this would be 64 'tabular objects' plus two entries for the
default system tables, so exceeding the configured count of 64 unique indexes.

With MaxNoOfUniqueIndexes=128 the limit is reached with 31 tables:

  31 * 4 +2 = 126    < 128

  32 * 4 + 2 = 130   > 128

So it seems as if not only unique indexes but both index types and tables 
themselves consume MaxNoOfUniqueHashIndexes entries.

It is possible to work around this by raising MaxNoOfUniqueHashIndexes
but a parameter named like this should really do what it name describes ...

How to repeat:
Try to execute the attached test.sql to create 64 tables,
with default cluser settings this will already fail at table 16
although it should be able to create all 64 tables just fine
within the given limits
[8 May 2006 22:46] Hartmut Holzgraefe
testfile creating 64 tables t1 - t64

Attachment: test.sql (text/x-sql), 8.73 KiB.

[9 May 2006 12:57] Bugs System
A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

[30 May 2006 11:27] Martin Skold
Pushed to 4.1.20,5.0.22, and 5.1.12
[31 May 2006 5:35] Jon Stephens
Thank you for your bug report. This issue has been committed to our
source repository of that product and will be incorporated into the
next release.

If necessary, you can access the source repository and build the latest
available version, including the bugfix, yourself. More information 
about accessing the source trees is available at

Additional info:

Documented bugfix in 4.1.21/5.0.23/5.1.12 changelogs. (4.1.20/5.1.22 were security releases.) Closed.