1. 04 Dec, 2016 6 commits
  2. 03 Dec, 2016 8 commits
  3. 02 Dec, 2016 2 commits
    • Jan Lindström's avatar
      MDEV-11168: InnoDB: Failing assertion: !other_lock ||... · 1e2b46d5
      Jan Lindström authored
      MDEV-11168: InnoDB: Failing assertion: !other_lock || wsrep_thd_is_BF(lock->trx->mysql_thd, FALSE) || wsrep_thd_is_BF(other_lock->trx->mysql_thd, FALSE)
      
      Merge fix from 10.1.
      1e2b46d5
    • Marko Mäkelä's avatar
      MDEV-11236 Failing assertion: state == TRX_STATE_NOT_STARTED · 33ed16c7
      Marko Mäkelä authored
      trx_state_eq(): Add the parameter bool relaxed=false, to
      allow trx->state==TRX_STATE_NOT_STARTED where a different
      state is expected, if an error has been reported.
      
      trx_release_savepoint_for_mysql(): Pass relaxed=true to
      trx_state_eq(). That is, allow the transaction to be idle
      when ROLLBACK TO SAVEPOINT is attempted after an error
      has been reported to the client.
      33ed16c7
  4. 01 Dec, 2016 6 commits
    • Sergei Golubchik's avatar
      update test results · cb78555f
      Sergei Golubchik authored
      cb78555f
    • Marko Mäkelä's avatar
      Merge pull request #262 from grooverdan/10.2-MDEV-9451-remove-innodb_buffer_pool_populate · 6a106812
      Marko Mäkelä authored
      MDEV-9451: Remove innodb_buffer_pool_populate from xtradb (10.2)
      6a106812
    • Marko Mäkelä's avatar
      MDEV-11426 Remove InnoDB INFORMATION_SCHEMA.FILES implementation · 0b66d3f7
      Marko Mäkelä authored
      MySQL 5.7 introduced WL#7943: InnoDB: Implement Information_Schema.Files
      to provide a long-term alternative for accessing tablespace metadata.
      The INFORMATION_SCHEMA.INNODB_* views are considered internal interfaces
      that are subject to change or removal between releases. So, users should
      refer to I_S.FILES instead of I_S.INNODB_SYS_TABLESPACES to fetch metadata
      about CREATE TABLESPACE.
      
      Because MariaDB 10.2 does not support CREATE TABLESPACE or
      CREATE TABLE…TABLESPACE for InnoDB, it does not make sense to support
      I_S.FILES either. So, let MariaDB 10.2 omit the code that was added in
      MySQL 5.7. After this change, I_S.FILES will report the empty result,
      unless some other storage engine in MariaDB 10.2 implements the interface.
      (The I_S.FILES interface was originally created for the NDB Cluster.)
      0b66d3f7
    • Jan Lindström's avatar
      MDEV-11168: InnoDB: Failing assertion: !other_lock ||... · 943baa3b
      Jan Lindström authored
      MDEV-11168: InnoDB: Failing assertion: !other_lock || wsrep_thd_is_BF(lock->trx->mysql_thd, FALSE) || wsrep_thd_is_BF(other_lock->trx->mysql_thd, FALSE)
      
          Problem was that we moved lock request to head of lock queue
          even when lock request has to wait.
      943baa3b
    • Marko Mäkelä's avatar
      MDEV-11432 Change the informational redo log format tag to "MariaDB 10.2.3" · 2c9bb42d
      Marko Mäkelä authored
      MariaDB 10.2 incorporates MySQL 5.7. MySQL 5.7.9 (the first GA release
      of the series) introduced an informational field to the InnoDB redo log
      header, which identifies the server version where the redo log files
      were created (initialized, resized or updated), in
      WL#8845: InnoDB: Redo log format version identifier.
      
      The informational message would be displayed to the user, for example
      if someone tries to start up MySQL 8.0 after killing a MariaDB 10.2 server.
      In the current MariaDB 10.2 source code, the identifier string would
      misleadingly say "MySQL 5.7.14" (using the hard-coded version number in
      univ.i) instead of "MariaDB 10.2.3" (using the contents of the VERSION
      file, the build system copies to config.h and my_config.h).
      
      This is only a cosmetic change. The compatibility check is based on a
      numeric identifier.
      
      We should probably also change the numeric identifier and some logic
      around it. MariaDB 10.2 should refuse to recover from a crashed MySQL 5.7
      instance, because the redo log might contain references to shared tablespaces,
      which are not supported by MariaDB 10.2. Also, when MariaDB 10.2 creates
      an encrypted redo log, there should be a redo log format version tag that
      will prevent MySQL 5.7 or 8.0 from starting up.
      2c9bb42d
    • Jan Lindström's avatar
      MDEV-11005: Incorrect error message when using ONLINE alter table with GIS · dc9f919f
      Jan Lindström authored
      Corrected error message when ONLINE alter table with GIS indexes is
      used on InnoDB.
      dc9f919f
  5. 30 Nov, 2016 3 commits
  6. 29 Nov, 2016 3 commits
  7. 27 Nov, 2016 7 commits
  8. 26 Nov, 2016 2 commits
  9. 25 Nov, 2016 3 commits
    • Marko Mäkelä's avatar
      618edd40
    • Marko Mäkelä's avatar
      Merge branch '10.2_warnings' of https://github.com/kevgs/server into kevgs-10.2_warnings · cc3aba26
      Marko Mäkelä authored
      Revert the XtraDB changes, because 10.2 does not currently build with XtraDB.
      
      Also omit some changes that need further investigation.
      
      Ensure that all callers of partition_info::get_clone() are passing this!=NULL.
      cc3aba26
    • Marko Mäkelä's avatar
      MDEV-11349 (2/2) Fix some bogus-looking Valgrind warnings · d247d649
      Marko Mäkelä authored
      buf_block_init(): Initialize buf_page_t::flush_type.
      For some reason, Valgrind 3.12.0 would seem to flag some
      bits in adjacent bitfields as uninitialized, even though only
      the two bits of flush_type were left uninitialized. Initialize
      the field to get rid of many warnings.
      
      buf_page_init_low(): Initialize buf_page_t::old.
      For some reason, Valgrind 3.12.0 would seem to flag all 32
      bits uninitialized when buf_page_init_for_read() invokes
      buf_LRU_add_block(bpage, TRUE). This would trigger bogus warnings
      for buf_page_t::freed_page_clock being uninitialized.
      (The V-bits would later claim that only "old" is initialized
      in the 32-bit word.) Perhaps recent compilers
      (GCC 6.2.1 and clang 4.0.0) generate more optimized x86_64 code
      for bitfield operations, confusing Valgrind?
      
      mach_write_to_1(), mach_write_to_2(), mach_write_to_3():
      Rewrite the assertions that ensure that the most significant
      bits are zero. Apparently, clang 4.0.0 would optimize expressions
      of the form ((n | 0xFF) <= 0x100) to (n <= 0x100). The redundant
      0xFF was added in the first place in order to suppress a
      Valgrind warning. (Valgrind would warn about comparing uninitialized
      values even in the case when the uninitialized bits do not affect
      the result of the comparison.)
      d247d649