Bug#12547647 UPDATE LOGGING COULD EXCEED LOG PAGE SIZE
This fix was accidentally pushed to mysql-5.1 after the 5.1.59 clone-off in bzr revision id marko.makela@oracle.com-20110829081642-z0w992a0mrc62s6w with the fix of Bug#12704861 Corruption after a crash during BLOB update but not merged to mysql-5.5 and upwards. In the Barracuda formats, the clustered index record no longer contains a prefix of off-page columns. Because of this, the undo log must contain these prefixes, so that purge and multi-versioning will continue to work. However, this also means that an undo log record can become too big to fit in an undo log page. (It is a limitation of the undo log that undo records cannot span across multiple pages.) In case the checks for undo log size fail when CREATE TABLE or CREATE INDEX is executed, we need a fallback that blocks a modification operation when the undo log record would exceed the maximum size. trx_undo_free_last_page_func(): Renamed from trx_undo_free_page_in_rollback(). Define the trx_t parameter only in debug builds. trx_undo_free_last_page(): Wrapper for trx_undo_free_last_page_func(). Pass the trx_t parameter only in debug builds. trx_undo_truncate_end_func(): Renamed from trx_undo_truncate_end(). Define the trx_t parameter only in debug builds. Rewrite a for(;;) loop as a while loop for clarity. trx_undo_truncate_end(): Wrapper for from trx_undo_truncate_end_func(). Pass the trx_t parameter only in debug builds. trx_undo_erase_page_end(): Return TRUE if the page was non-empty to begin with. Refuse to erase empty pages. trx_undo_report_row_operation(): If the page for which the undo log was too big was empty, free the undo page and return DB_TOO_BIG_RECORD. rb:749 approved by Inaam Rana
Showing
Please register or sign in to comment