I stumbled upon an issue with the compressed row format in the InnoDB plugin.

The issue is that the maximum allowed key size depends on the version of libz that InnoDB plugin is linked against.

It means that this statement:

CREATE TABLE t1(c TEXT, PRIMARY KEY (c(439)))
ENGINE=InnoDB ROW_FORMAT=COMPRESSED KEY_BLOCK_SIZE=1 CHARSET=ASCII;

will succeed with one version of libz, but fail with another.

Whether it is a bug is debatable. It is definitely a corner case but it has some nasty side effects. Eg. a table dump made on one server can refuse to load on another server (not sure of possible effects of a libz upgrade).

The reason for the dependency on libz version is in function page_zip_empty_size():

lint size = zip_size
/* subtract the page header and the longest
uncompressed data needed for one record */
- (PAGE_DATA
+ PAGE_ZIP_DIR_SLOT_SIZE
+ DATA_TRX_ID_LEN + DATA_ROLL_PTR_LEN
+ 1/* encoded heap_no==2 in page_zip_write_rec() */
+ 1/* end of modification log */
- REC_N_NEW_EXTRA_BYTES/* omitted bytes */)
/* subtract the space for page_zip_fields_encode() */
- compressBound(2 * (n_fields + 1));

On my machine, compressBound() for n_fields=4 returns 21 for the bundled zlib (mysql 5.1.34) but 23 for my system zlib (Ubuntu Hardy x86_64).

I would suggest to change the code so that the estimate on max key size does not depend on whatever zlib returns. The zlib manual [www.zlib.net] says this:

"destLen is the total size of the destination buffer, which must be at least 0.1% larger than sourceLen plus 12 bytes"

Eg, rounding up, this would give the 23 bytes returned by my system libz compressBound(). This is slightly more pessimistic than some versions of compressBound() apparently, but much better to have the same limit on all systems rather than getting slightly larger key sizes only on some.

Hope this helps (and that this is the correct place to post it),

- Kristian.