PBXT 1.0.10i

Milestone information

Project:
PBXT
Series:
rc4
Version:
1.0.10i
Released:
2010-03-17  
Registrant:
Paul McCullagh
Release registered:
2010-03-17
Active:
No. Drivers cannot target bugs and blueprints to this milestone.  

Download RDF metadata

Activities

Assigned to you:
No blueprints or bugs assigned to you.
Assignees:
No users assigned to blueprints and bugs.
Blueprints:
No blueprints are targeted to this milestone.
Bugs:
No bugs are targeted to this milestone.

Download files for this release

After you've downloaded a file, you can verify its authenticity using its MD5 sum or signature. (How do I verify a download?)

File Description Downloads
download icon pbxt-1.0.10-rc.tar.gz (md5) Compressed archive of all sources 21
last downloaded 41 weeks ago
Total downloads: 21

Release notes 

------- 1.0.10i RC4 - 2010-03-17

RN312: Fixed bug #534361: Valgrind error: write of uninitialised bytes in xt_flush_indices()

RN311: Fixed ilog corruption when running out of disk space during an index flush operation, which lead to corruption of the index.

------- 1.0.10h RC4 - 2010-02-25

RN310: Fixed Windows atomic INC/DEC operations, which lead to atomic R/W lock not working correctly. The result was that some index entries were not foound.

RN309: Fixed a bug that caused a crash when the index was corrupted. The crash occurs if the index page in not completely written, and an item in the index has a bad length.

RN308: Fixed bug #509803: can't run tpcc (cannot compare FKs that rely on indexes of different length).

------- 1.0.10g RC4 - 2010-02-11

RN307: 2010-02-15: Set the internal version number 1.0.10g.

RN306: All tests now run with MySQL 5.1.42.

RN305: Fixed a bug that could cause a crash in filesort. The problem was that the return row estimate was incorrect, which caused the result of estimate_rows_upper_bound() to overflow to zero. Row estimate has been changed, and no longer takes into account deleted rows (so the row estimate is now a maximum).

RN304: Fixed bug #513012: On a table with a trigger the same record is updated more than once in one statement

------- 1.0.10f RC4 - 2010-01-29

RN303: Fix back-ported from 1.1: Fixed a bug in the record cache that caused PBXT to think it had run out of cache memory. The effect was that PBXT used less and less cache over time. The bug occurs during heavy concurrent access on the record cache. The affect is the PBXT gets slower and slower.

RN302: Fix back-ported from 1.1: Corrected a problem that sometimes caused a pause in activity when the record cache was full.

------- 1.0.10e RC4 - 2010-01-25

RN301: Fixed index statistics calculation. This bug lead to the wrong indices being selected by the optimizer because all indices returned the same cost.

RN300: Fixed bug #509968: START TRANSACTION WITH CONSISTENT SNAPSHOT breaks transactional flow.

RN299: Fixed bug #509218: Server asserts with Assertion `mutex->__data.__owner == 0' failed on high concurrency OLTP test.

------- 1.0.10d RC4 - 2010-01-11

RN298: Fixed a bug that caused huge amounts of transaction log to be written when pbxt_flush_log_at_trx_commit = 2.

------- 1.0.10c RC4 - 2009-12-29

RN297: Updated "LOCK TABLES ... READ LOCAL" behavior to be more restrictive and compatible with InnoDB

RN296: Fixed bug #499026: START TRANSACTION WITH CONSISTENT SNAPSHOT does not work for PBXT

------- 1.0.10 RC4 - 2009-12-18

RN295: PBXT tests now all run with MySQL 5.1.41.

RN294: Fixed bug #483714: a broken table can prevent other tables from opening

RN293: Added system variable pbxt_flush_log_at_trx_commit. The value of this variable determines whether the transaction log is written and/or flushed when a transaction is ended. A value of 0 means don't write or flush the transaction log, 1 means write and flush and 2 means write, but do not flush. No matter what the setting is choosen, the transaction log is written and flushed at least once per second.

Changelog 

This release does not have a changelog.

0 blueprints and 0 bugs targeted

There are no feature specifications or bug tasks targeted to this milestone. The project's maintainer, driver, or bug supervisor can target specifications and bug tasks to this milestone to track the things that are expected to be completed for the release.

This milestone contains Public information
Everyone can see this information.