-
unknown authored
number 1: "./mtr --mysqld=--default-storage-engine=maria backup" restored no rows (forgot to flush data pages before my_copy(), and also the maria_repair() used by ha_maria::restore() needed a correct data_file_length to not miss rows). [note that BACKUP TABLE will be removed anyway in 5.2] number 2: "./mtr --mysqld=--default-storage-engine=maria bootstrap" caused segfault (uninitialized variable) number 3: "./mtr --mysqld=--default-storage-engine=maria check" showed warning in CHECK TABLE (maria_create() created a non-empty data file with data_file_length==0). storage/maria/ha_maria.cc: in ha_maria::backup, need to flush the data file before copying it, otherwise data misses from the copy (bug 1) storage/maria/ma_bitmap.c: when allocating data at the end of the bitmap, best_data is at "end", should not be left to 0 (bug 2) storage/maria/ma_check.c: _ma_scan_block_record() is used in QUICK repair. It relies on data_file_length. RESTORE TABLE mixes the MAI of an empty table (so, data_file_length==0) with an non-empty MAD, and does a QUICK repair; that got fooled (thought it had hit EOF immediately, so found no records) (bug 1) storage/maria/ma_create.c: At the end of maria_create() we have, in the index file, data_file_length==0, while the data file has a bitmap page (8192). This inconsistency makes CHECK TABLE rightly complain. Fixed by not creating a first bitmap page during maria_create() (also saves disk space) (bug 3) Question for Monty. storage/maria/ma_extra.c: A function to flush the data and index files before one can use OS syscalls (reads, writes) on those files. For example, ha_maria::backup() does a my_copy() of the data file and so all cached pieces of this file must be sent to the OS (bug 1) This function will have to be used elsewhere in Maria, several places have not been updated when we added pagecache-ing of the data file (they still only flush the index file), they are probable bugs. storage/maria/maria_def.h: new function. Needs to be visible from ha_maria::backup.
72c3c369