commit f6ed777697db4ad7aee1e98c53243dced2b5891c
Author: Chenyu Yan <seayan@outlook.com>
Date:   Thu Dec 29 16:10:25 2016 -0800

    Fix BIG_TIMEOUT constant

    Summary: Update the constant to reflect what the comments indicates.

    Reviewed By: gunnarku

    Differential Revision: D4374476

    fbshipit-source-id: dd7f484

We expose @@rocksdb_skip_unique_check_tables anyway, so it's not
really disabled.

- Fix include paths, add suite.opt
- Add a test for @@rocksdb_supported_compression_types
Now all tests pass, except rocksdb_sysvars.rocksdb_rpl_skip_tx_api_basic

- It's from a webscalesql feature that we dont have
- MyRocks ignores it anyway

rocksdb.cons_snapshot_read_committed test used to crash.
This happened, because
- MyRocks produces an error when one attempts to do a START TRANSACTION
  WITH CONSISTENT SNAPSHOT with @@tx_isolation=REPEATABLE_READ
- MariaDB's SQL layer didn't assume that errors are possible inside
  hton->start_constistent_snapshot() call.

The test still fails but at least we do not try to run it with
wrong binlog_format.

Looked though the code: MariaDB's method of doing START TRANSACTION
WITH CONSISTENT SNAPSHOT doesn't require mysql_bin_log_lock_commits
calls.

Run it only with binlog_format=row, update test result

The 'combinations' system in MTR ignores settings from $testname.cnf,
and tries to run RBR test with binlog_format=mixed.

Fixed by using "source include/have_binlog_format_row.inc" which tells
MTR to only run the test with binlog_format=ROW.
The test still needs its $testname.cnf to include suite/rpl/my.cnf. This
is necessary to setup replication

(Using "source include/master-slave.inc" will have MTR set up replication
for the test, but only as long as the testsuite doesn't have its own
suite/rocksdb/my.cnf.  We do have that file (and it doesn't set up
replication), so we need to have $testname.cnf to setup replication).

- port Regex_list_handler from facebook/mysql-5.6/sql/handler.cc
  put it into a separate file in storage/rocksdb directory

- Adjust the build process so that the main library is build with
  Regex_list_handler (which has dependencies on the server),
  while RocksDB tools are built without it.

- Un-comment @@rdb_collation_exceptions handling in ha_rocksdb.cc
- Also adjust rocksdb_set_collation_exception_list() to free the
  old variable value and alloc the new one.

Also update test results (MariaDB's dialect changes)

- Make ha_rocksdb::check_if_supported_inplace_alter() take into
  account the Alter_inplace_info::ALTER_PARTITIONED flag

- Adjust the testcase to work in MariaDB

Making read-free replication to work is filed as MDEV-10976

The test relies on having userstat enabled, which is not ON
by default in MariaDB.

This fixes
- rocksdb.col_opt_not_null
- rocksdb.col_opt_null
- rocksdb.type_date_time

MariaDB has a different checksumming algorithm. Old one
can be used by setting @@old=1

Failure to do so caused the command not to be run, and test failed

The test stopped giving deadlock errors after the previous cset.

Failure to do so caused a failure in rocksdb.rocksdb test.
When test_if_cheaper_ordering computes is_covering= ...,
- MySQL calls table->file->primary_key_is_clustered()
- MariaDB calls (table->file->index_flags(nr, 0, 1) &
                          HA_CLUSTERED_INDEX)

The first produces true, the second used to produce false.

MariaDB produces warnings when INSERT IGNORE hits a duplicate (this
was introduced in MEV-5168)

... due to different index statistics
Make statistics calculations in MariaRocks produce the same values
that MyRocks produces.

Added a comment in rdb_datadic.cc

Update the test results (checked)

- EXPLAIN result differences are due to MariaDB's MDEV-11172
- Don't print the value of rocksdb_supported_compression_types
  to .result file
- The rest is trivial Maria-fication

- EXPLAIN is different
- error message is
- the output order is different, because MySQL knows when to use
  ha_partition::handle_unordered_scan_next_partition.
  Reading the table data without any ordering happens to produce
  MariaDB uses  ha_partition::handle_ordered_index_scan for this index
  scan (this is a deficiency), which causes it to produce the row with
  pk=1 first.


  MariaDB uses

This cset just re-uses the approach from facebook/mysql-5.6 (Perhaps we
will have something different for MariaDB in the end).

For now this is:
Port this fix
  dd7eeae69503cb8ab6ddc8fd9e2fef451cc31a32
  Issue#250: MyRocks/Innodb different output from query with order by on table with index and decimal type
  Summary:
  Make open_binary_frm() set TABLE_SHARE::primary_key before it computes

Also add the patch for
  https://github.com/facebook/mysql-5.6/issues/376

Also do similar result updates for:
- rocksdb.type_date_time_indexese
- rocksdb.type_fixed_indexes

Upadte test results (see jira entry for investigation about
the source of the differences)

Backport the fix for BUG#81810 from facebook/mysql-5.6 tree.
Added the original testcase.

rocksdb.type_text_indexes still fails due to another problem.

- MariaDB produces a warning instead of error when the key
  length is too long
- Trivial test results updates
- rocksdb.rocksdb still fails but this commit makes some progress.

The warning
"ORDER BY ignored as there is a user-defined clustered index in the table 't1'
was missing.

The reason is different condition in copy_data_between_tables():
MariaDB has a change, it uses

  to->file->ha_table_flags() & HA_TABLE_SCAN_ON_INDEX

while MySQL uses:

  to->file->primary_key_is_clustered()).

For some reason, MyRocks didn't have HA_TABLE_SCAN_ON_INDEX flag.
It should have one, will raise that with upstream, too.