- lifting a limit: INSERT|REPLACE SELECT and LOAD DATA always prevented...
- lifting a limit: INSERT|REPLACE SELECT and LOAD DATA always prevented versioning, now what do so is if the table is empty. - lifting another limit: versioning was disabled if table had more than one unique index - correcting test of statement-based binlogging, when converting read locks to TL_READ_NO_INSERT KNOWN_BUGS.txt: removing mostly fixed limitation (see ha_maria.cc) mysql-test/r/maria-mvcc.result: result update mysql-test/t/maria-mvcc.test: now when table is empty it does not do versioning, so test hung; inserting one row at start of the test, to enable versioning. sql/sql_parse.cc: Maria team wrongly removed this "break", thanks Davi for noticing storage/maria/ha_maria.cc: - We used to prevent versioning in INSERT/REPLACE SELECT and LOAD DATA, because the index rebuild done by bulk insert sometimes, is unsafe when versioning is on. Here we change that: in store_lock(), if the table is empty (which is required for index rebuild to be used), we disable versioning; in start_bulk_insert(), we don't do index rebuild if versioning is enabled. - Test for statement-based binlogging was incomplete: statement-based binlogging is on for this statement if binlog is open and statement has binlogging enabled and statement is not doing row-based binlogging storage/maria/ma_open.c: Monty and I agreed that it's ok to have versioning on a table with more than one unique index: if an INSERT hits a duplicate key when inserting the second index' key, no other thread should be able to touch the first index' just-inserted key, because that key has an uncommitted transaction id, so the first thread should have time to remove the first index' key.
Showing
Please register or sign in to comment