PBXT 1.0.10n

------- 1.0.10n RC4 - 2010-04-28

RN319: Fix RN1/3 and RN1/4 back-ported from 1.1: Fixed a deadlock that could occur during low index cache situations and added some checks for index corruption, and added the try lock variation for R/W locks.

RN318: Fixed a bug in the atomic R/W lock. This bug occurred on multi-core Linux when under extrem load. The affect was that an index lookup could fail. The index was not corrupted.

------- 1.0.10m RC4 - 2010-03-29

RN317: This change prevents a unscheduled checkpoint from occurring when the sweeper has work to do. Checkpoint required due to the Checkpoint threshold reached are done as usual.

------- 1.0.10k RC4 - 2010-03-29

RN316: Set the maximum delay, while waiting for previous transactions to commit to 1/100s. This situation occurs when cleanup begins of a long running transaction.

RN315: Fixed a bug that could lead to a data log error, for example: Data log not found: '.../dlog-129602.xt'. This error occurred after a duplicate key error, dending on the table structure, because the row buffer was not restored after writing an extended record.

RN314: Server startup time could be very long when data logs become large because the log size was not save in the header when a data log is full.

------- 1.0.10j RC4 - 2010-03-24

RN313: Fixed an error in the calculation of the handle data record (.xtd files) size when AVG_ROW_LENGTH is set explicitly to a value less than 12. For example:

CREATE TABLE objs (
  id int(10) unsigned NOT NULL,
  objdata mediumblob NOT NULL,
  PRIMARY KEY (id)
) ENGINE=PBXT AVG_ROW_LENGTH=10

This table definition previously lead to corruption of the table because the handle data record was set to 24 (14+10), which is less than the minimum (for variable length records) handle data record size of 26.

This minimum consists of 14 byte record header and 12 bytes reference to the extended record data (the part of the record in the data log).

Tip: when setting AVG_ROW_LENGTH you should normally add 12 to the average row length estimate to ensure that the average length part of the record is always in the handle data file. This is important, for example if you wish to make sure that the rows used to build indexes are in the handle data file. CHECK TABLE tells you how many rows are in the "fixed length part" of the record (output in MySQL error log). In the example above, this would be AVG_ROW_LENGTH=17.

The maximum size of a field can be calculated adding the maximum byte size as described here: http://dev.mysql.com/doc/refman/5.1/en/storage-requirements.html, and then add the following values, depending on the byte size:

byte size <= 240, add 1
byte size < 2^16 (65536), add 3
byte size < 2^24 (16777216), add 4
byte size > 2^24, add 5