-
Guilhem Bichot authored
- 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.
81d3d3ac