- 26 Sep, 2017 5 commits
-
-
Marko Mäkelä authored
-
Marko Mäkelä authored
In the temporary file that is applied by row_log_table_apply(), we must identify whether the records contain the extra header for instantly added columns. For now, we will allocate an additional byte for this for ROW_T_INSERT and ROW_T_UPDATE records when the source table has been subject to instant ADD COLUMN. The ROW_T_DELETE records are fine, as they will be converted and will only contain 'core' columns (PRIMARY KEY and some system columns) that are converted from dtuple_t. rec_get_converted_size_temp(), rec_init_offsets_temp(), rec_convert_dtuple_to_temp(): Add the parameter 'status'. rec_set_n_add_field(): Simplify the interface to resemble rec_get_n_add_field(). rec_init_offsets_comp_ordinary(): Handle the new rec_leaf_format constant REC_LEAF_TEMP_COLUMNS_ADDED. rec_get_converted_size_comp_prefix_low(), rec_convert_dtuple_to_rec_comp(): Handle index->is_instant() for both temp and !temp.
-
Marko Mäkelä authored
-
Marko Mäkelä authored
-
Marko Mäkelä authored
-
- 25 Sep, 2017 17 commits
-
-
Marko Mäkelä authored
-
Marko Mäkelä authored
-
Marko Mäkelä authored
Ensure that no adaptive hash index exists for any system tables, so that the blocked TRUNCATE TABLE t1 will not block the concurrent TRUNCATE TABLE t2.
-
Marko Mäkelä authored
Ensure that no adaptive hash index exists for any system tables, so that the blocked TRUNCATE TABLE t1 will not block the concurrent TRUNCATE TABLE t2.
-
Marko Mäkelä authored
-
Marko Mäkelä authored
-
Will authored
Made a few links in README.md secure (https).
-
Marko Mäkelä authored
This bug is a regression caused by the code refactoring in commit f5a833c3. It was not present in any release of the MariaDB server. The bug affects table-rebuilding ALTER TABLE when the source table is in ROW_FORMAT=REDUNDANT and contains no virtual columns. row_log_table_low_redundant(): Log virtual column data only if virtual columns are present.
-
Marko Mäkelä authored
-
Marko Mäkelä authored
-
Marko Mäkelä authored
-
Marko Mäkelä authored
-
Marko Mäkelä authored
In TRUNCATE TABLE, clear the 'instant' status of a table. TODO: Do the same when the table becomes empty dict_col_t::remove_instant(): Remove the instantness of a column. dict_index_t::remove_instant(): Remove the instantness of a clustered index.
-
Marko Mäkelä authored
-
Marko Mäkelä authored
-
Marko Mäkelä authored
-
Marko Mäkelä authored
This bug is a regression caused by the code refactoring in commit f5a833c3. It was not present in any release of the MariaDB server. The bug affects table-rebuilding ALTER TABLE when the source table is in ROW_FORMAT=REDUNDANT and contains no virtual columns. row_log_table_low_redundant(): Log virtual column data only if virtual columns are present.
-
- 24 Sep, 2017 5 commits
-
-
Varun Gupta authored
The issue was that r_loops, r_rows and r_filtered in ANALYZE FORMAT= JSON were not calculated for the table on which we were performing the MRR scan in the BKA join Fixed this by adding respective counter in the JOIN_TAB_SCAN_MRR::open and JOIN_TAB_SCAN_MRR::next
-
Varun Gupta authored
The problem is there is an overflow for the key_file_length. Added the maximum limit for the key_file_length
-
Marko Mäkelä authored
The ALTER TABLE…IMPORT TABLESPACE adjustment code that was introduced by WL#5522 in MySQL 5.6 is incorrectly invoking rec_get_status() on a ROW_FORMAT=REDUNDANT record to determine if a record is a leaf page record. The function rec_get_status(rec) is only to be called on ROW_FORMAT=COMPACT, DYNAMIC or COMPRESSED records.
-
Marko Mäkelä authored
-
Marko Mäkelä authored
The ALTER TABLE…IMPORT TABLESPACE adjustment code that was introduced by WL#5522 in MySQL 5.6 is incorrectly invoking rec_get_status() on a ROW_FORMAT=REDUNDANT record to determine if a record is a leaf page record. The function rec_get_status(rec) is only to be called on ROW_FORMAT=COMPACT, DYNAMIC or COMPRESSED records.
-
- 23 Sep, 2017 13 commits
-
-
Vladislav Vaintroub authored
-
Marko Mäkelä authored
-
Marko Mäkelä authored
Revert any changes that are not needed any more. Most of the code submitted by Vinchen has been refactored so far. The redo log format changes are as they were submitted by Vinchen. FIXME: On rollback, convert the record to "old" format if the values match the 'default row' ones. There should be no need to write any new BLOBs during rollback. If we created new BLOBs during rollback, crash recovery could become very tricky. TODO: Review the changes to row0upd.cc, row0umod.cc. For new inserts and updates, if the suffix of instantly added columns match the 'default row', we can omit those fields from the clustered index record. If a non-default value is assigned to the last column, then all columns will have to be materialized. TODO: Implement update-in-place of the 'default row' record (for performing instant ADD COLUMN after instant ADD COLUMN). TODO: Implement and test rollback of the 'default row' record. TODO: Test crash recovery. Ensure that the ADD COLUMN operation is being rolled back if the server is killed during it. Also test crash recovery of DML operations on tables that were subject to instant ADD COLUMN, using all supported ROW_FORMAT (REDUNDANT, COMPACT, DYNAMIC).
-
Sergei Golubchik authored
3-argument form of DATE_FORMAT
-
Sergei Golubchik authored
-
Sergei Golubchik authored
-
Sergei Golubchik authored
-
Sergei Golubchik authored
-
Marko Mäkelä authored
-
Marko Mäkelä authored
-
Marko Mäkelä authored
-
Marko Mäkelä authored
-
Marko Mäkelä authored
-