- 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.

1 files changed, 1 insertions, 10 deletions

diff --git a/KNOWN_BUGS.txt b/KNOWN_BUGS.txt
index a69384910e2..12f9c2fa123 100644
--- a/KNOWN_BUGS.txt
+++ b/KNOWN_BUGS.txt
@@ -54,16 +54,7 @@ Known bugs that are planned to be fixed later
 =============================================
 
 LOCK TABLES .. WRITE CONCURRENT is mainly done for testing MVCC.  Don't
-use this in production.  Things that is not working if you are using
-this on a table:
-
-- INSERT/REPLACE ... SELECT on an empty table may cause crashes or
-  wrong results if someone else is doing writes on the table during repair
-  or someone is doing selects during the repair index phase.
-
-INSERT ... SELECT, REPLACE ... SELECT and LOAD DATA are blocking
-inserts and SELECT for the table.  They should only have to do this if
-the destination is empty (as then we are using fast index rebuild).
+use this in production.
 
 Missing features that is planned to fix before Beta
 ===================================================