Changes in Twitter MySQL 5.5.23.t6

Earlier this week we pushed to Github the sixth iteration of Twitter MySQL. Here's some highlights:

Bugs Fixed

• Bug#65469: Infinite loop when opening a corrupted table
  If a permanently corrupted page was read, InnoDB would forever keep trying to read the page.
• Bug#65310: Crash with partition pruning and impossible condition
  Reading from a partitioned table using a impossible (e.g. where, between, etc) condition could lead to a crash if all partitions are pruned and the optimizer attempts to obtain the number of rows in the table. The problem occurs because even though no partitions are used, the optimizer might still attempt to perform (e.g. range) analysis where an estimate of the the number of rows is needed, but the partition storage engine wasn't prepared to provide it.

Functionality Added or Changed

• Add partitioning functions for YMD and YMDH or equivalent
  Added a UTC_EXTRACT(unit FROM date) function that extracts parts from a date and returns them as an integer in a specified format. The function is modeled after EXTRACT(), but differs in that it uses UTC for all of its calculations. The supported unit specifiers are YEAR_MONTH_DAY and YEAR_MONTH_DAY_HOUR, which returns a representation of the date argument as a value in the YYYYMMDD or YYYYMMDDHH format.
  This function is intended to facilitate partitioning by days, specially when applied to TIMESTAMP values. It allows partitions to be named in a more human-readable format like YYYYMMDD.
• Export the last know good binlog position as a status variable from InnoDB
  Introduced two new status variables that export the master binary log name and position of a slave as stored by InnoDB. Whenever the SQL thread commits a transaction, InnoDB also commits the master binary log name and position to the system tablespace. Now this information can be retrieved through the Innodb_mysql_master_log_file and Innodb_mysql_master_log_pos status variables.
  
  

  It is worth noting that the position stored within InnoDB might not match the actual position of the SQL thread. The position is only updated when the SQL thread applies an event that uses an InnoDB table and causes a read-write transaction to be committed. For example, an UPDATE statement which does not change any rows is considered a read-only transaction. 
• Report counters for InnoDB corruption events so that they are alertable
  Introduced status variables that expose a counter of page corruption and table corruption events so that they can be alerted on without scanning the error log files.
• Improve obscure "Got error -1 when reading table" messages
  The problem was that handler originated errors printed to the error log sometimes do not indicate the precise nature of the problem. This is especially an issue with InnoDB because it cannot always convert an internal InnoDB error code to a MySQL error code.
  InnoDB now provides an additional (and more detailed) error message if it cannot convert the error code. Additionally, errors related to a statement being interrupted are no longer printed to the error log.
  Also, the error message format was changed from "Got error when reading table" to "Error when reading table: error message (error number)" in order to distinguish the offending error message.
• Google Breakpad crash reporting system
  Google's Breakpad is now used to generate minimal crash dump information when the server process (mysqld) crashes. The minidump file generated by breakpad contains a list of the executable and shared libraries loaded in the process, the state of the processor register and a stack trace for each thread, and miscellaneous information about the system and the reason for the dump. Minidumps are significantly smaller than core files, making them more practical for collection and processing.

For a more complete look at what's new in this version, please see the change history and documentation. Feedback, bug reports, etc, can be submitted directly to the issue tracker.