MySQL Bugs: #19623: UniqueHashIndexes resource leak

Bug #19623	UniqueHashIndexes resource leak
Submitted:	8 May 2006 22:50	Modified:	31 May 2006 7:35
Reporter:	Hartmut Holzgraefe
Status:	Closed
Category:	Server: Cluster	Severity:	S2 (Serious)
Version:	4.1, 5.0, 5.1	OS:	Linux (linux)
Assigned to:	Martin Skold	Target Version:

Description:
Consider a cluster table of the following form:

CREATE TABLE t_counter_ (
  i INT NOT NULL AUTO_INCREMENT PRIMARY KEY,
  k VARCHAR(16) NOT NULL UNIQUE
) ENGINE=NDB;

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

testfile creating 64 tables t1 - t64

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

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:

  http://lists.mysql.com/commits/6141

Pushed to 4.1.20,5.0.22, and 5.1.12

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
    http://www.mysql.com/doc/en/Installing_source_tree.html

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.