- 17 Nov, 2017 1 commit
-
-
Alexander Barkov authored
-
- 16 Nov, 2017 5 commits
-
-
Vladislav Vaintroub authored
-
Vladislav Vaintroub authored
is set to true, as it should. Copy and modify original io_win.h header file to a different location (as we cannot patch anything in submodule). Make sure modified header is used.
-
Alexey Botchkov authored
Result unescaping added.
-
Jan Lindström authored
This is caused by following change: commit 95d29c99f01882ffcc2259f62b3163f9b0e80c75 Author: Marko Mäkelä <marko.makela@oracle.com> Date: Tue Nov 27 11:12:13 2012 +0200 Bug#15920445 INNODB REPORTS ER_DUP_KEY BEFORE CREATE UNIQUE INDEX COMPLETED There is a phase during online secondary index creation where the index has been internally completed inside InnoDB, but does not 'officially' exist yet. We used to report ER_DUP_KEY in these situations, like this: ERROR 23000: Can't write; duplicate key in table 't1' What we should do is to let the 'offending' operation complete, but report an error to the ALTER TABLE t1 ADD UNIQUE KEY (c2): ERROR HY000: Index c2 is corrupted (This misleading error message should be fixed separately: Bug#15920713 CREATE UNIQUE INDEX REPORTS ER_INDEX_CORRUPT INSTEAD OF DUPLICATE) row_ins_sec_index_entry_low(): flag the index corrupted instead of reporting a duplicate, in case the index has not been published yet. rb:1614 approved by Jimmy Yang Problem is that after we have found duplicate key on primary key we continue to get necessary gap locks in secondary indexes to block concurrent transactions from inserting the searched records. However, search from unique index used in foreign key constraint could return DB_NO_REFERENCED_ROW if INSERT .. ON DUPLICATE KEY UPDATE does not contain value for foreign key column. In this case we should return the original DB_DUPLICATE_KEY error instead of DB_NO_REFERENCED_ROW. Consider as a example following: create table child(a int not null primary key, b int not null, c int, unique key (b), foreign key (b) references parent (id)) engine=innodb; insert into child values (1,1,2); insert into child(a) values (1) on duplicate key update c = 3; Now primary key value 1 naturally causes duplicate key error that will be stored on node->duplicate. If there was no duplicate key error, we should return the actual no referenced row error. As value for column b used in both unique key and foreign key is not provided, server uses 0 as a search value. This is naturally, not found leading to DB_NO_REFERENCED_ROW. But, we should update the row with primay key value 1 anyway as requested by on duplicate key update clause.
-
Jun Su authored
-
- 15 Nov, 2017 2 commits
-
-
Oleksandr Byelkin authored
Fix of nondebuging version issue
-
Marko Mäkelä authored
-
- 14 Nov, 2017 2 commits
-
-
Igor Babaev authored
than the query itself ACL checks were not properly supported for tables used in CTE specifications. This patch fixes the problem.
-
Alexey Botchkov authored
Check for the empty 'coordinates' array.
-
- 13 Nov, 2017 4 commits
-
-
Vladislav Vaintroub authored
-
Vladislav Vaintroub authored
-
Marko Mäkelä authored
-
Marko Mäkelä authored
-
- 12 Nov, 2017 1 commit
-
-
Marko Mäkelä authored
-
- 11 Nov, 2017 1 commit
-
-
Alexey Botchkov authored
Character bigger than 0x60 wasn't handled properly inside a numeric constant.
-
- 10 Nov, 2017 4 commits
-
-
Igor Babaev authored
This patch effectively blocks the optimization that uses multiple equalities for ORDER BY to remove tmp table in the case when the first table happens to be the result of materialization of a semi-join nest. Currently there is no code at the execution level that would support the optimization in this case.
-
Marko Mäkelä authored
-
Marko Mäkelä authored
rec_get_offsets_func(): Relax a bogus debug assertion. It would fail when we are operating on a copied prefix of a node pointer record.
-
Marko Mäkelä authored
row_log_table_apply_op(): Remove references to dict_table_t::n_vcols. Virtual column information is no longer being written to the log. row_log_t: Remove the unused fields n_old_col, n_old_vcol.
-
- 09 Nov, 2017 8 commits
-
-
Marko Mäkelä authored
When MySQL 5.7 introduced indexed virtual columns, it introduced several bugs into the online table-rebuilding ALTER, that is, the row_log_table_apply() family of functions. The online_log format that was introduced for online table-rebuilding ALTER in MySQL 5.6 should be sufficient. Ideally, any indexed virtual column values would be evaluated based on the log records in the temporary file. There is no need to log virtual column values. (For ADD INDEX, that is row_log_apply(), we always must log the values of the keys, no matter if the columns are virtual.) Because omitting the virtual column values removes any chance of row_log_table_apply() working with indexed virtual columns, we will for now refuse LOCK=NONE in table-rebuilding ALTER operations when indexes on virtual columns exist. This restriction would be lifted in MDEV-14341. innobase_indexed_virtual_exist(): New predicate, to determine if indexed virtual columns exist in a table definition. ha_innobase::check_if_supported_inplace_alter(): Refuse online rebuild if indexed virtual columns exist. rec_get_converted_size_temp_v(), rec_convert_dtuple_to_temp_v(): Remove. row_log_table_delete(), row_log_table_update(, row_log_table_insert(): Remove parameters for virtual columns. trx_undo_read_v_rows(): Remove the col_map parameter. row_log_table_apply(): Do not deal with virtual columns.
-
Sergei Petrunia authored
-
Monty authored
-
Marko Mäkelä authored
-
Marko Mäkelä authored
MDEV-14333 Mariabackup --apply-log-only crashes if incomplete transactions with update_undo logs are present trx_undo_free_prepared(): Relax the assertion for mariabackup --apply-log-only.
-
Alexander Barkov authored
-
Alexander Barkov authored
-
Oleksandr Byelkin authored
MDEV-14164: Unknown column error when adding aggregate to function in oracle style procedure FOR loop Make differentiation between pullout for merge and pulout of outer field during exists2in transformation. In last case the field was outer and so we can safely start from name resolution context of the SELECT where it was pulled. Old behavior lead to inconsistence between list of tables and outer name resolution context (which skips one SELECT for merge purposes) which creates problem vor name resolution.
-
- 08 Nov, 2017 3 commits
-
-
Marko Mäkelä authored
-
Alexander Barkov authored
There was a problem in the recent patch for MDEV-10817: get_date() must "return true" on null_value rather than "return 0" (forgot to fix Item_sum_hybrid::get_date() after copying and pasting from Item_sum_hybrid::val_str()).
-
Marko Mäkelä authored
-
- 07 Nov, 2017 7 commits
-
-
Marko Mäkelä authored
-
Marko Mäkelä authored
FlushObserver::flush(): Never discard unwritten changes. We do not want to risk corrupting the system tablespace or .ibd files that are not part of a table-rebuilding ALTER.
-
Marko Mäkelä authored
Ever since MDEV-10813 cleaned up InnoDB use of atomic memory operations and made buf_block_fix() an atomic operation, some conditions around buf_block_fix() have been unnecessary.
-
Alexander Barkov authored
-
Vesa Pentti authored
-
Alexander Barkov authored
-
Alexander Barkov authored
This problem was earlier fixed by the patch for MDEV-8910. Adding tests only.
-
- 06 Nov, 2017 2 commits
-
-
Vladislav Vaintroub authored
-
Marko Mäkelä authored
-