1. 23 May, 2022 3 commits
  2. 20 May, 2022 9 commits
  3. 19 May, 2022 1 commit
    • Oleg Smirnov's avatar
      MDEV-28246 Optimizer uses all partitions after upgrade to 10.3 · 40d9dbb2
      Oleg Smirnov authored
      Cause: a copy of the joined TABLE_LIST is created during multi_update::prepare
      and TABLE::pos_in_table_list of the tables are set to point to the new
      TABLE_LIST object. This prevents some optimization steps to perform correctly.
      Solution: do not update pos_in_table_list during multi_update::prepare
      40d9dbb2
  4. 18 May, 2022 4 commits
    • KiyoshiTakeda's avatar
      MDEV-14642 Assertion 'table->s->db_create_options ==... · 8881c010
      KiyoshiTakeda authored
      MDEV-14642 Assertion 'table->s->db_create_options == part_table->s->db_create_options' failed in compare_table_with_partition
      
      When trying to execute ALTER TABLE EXCHANGE PARTITION with different
      definitions, assertion
      
          table->s->db_create_options == part_table->s->db_create_options
      
      failed in compare_table_with_partition().
      
      However, this execution should not be allowed since executing
      'exchange partition' requires the identical structure of the two tables.
      
      To fix the problem, I deleted the assertion code and added code that
      returns an error that indicates tables have different definitions.
      
      Reviewed By: Nayuta Yanagisawa
      8881c010
    • Sergei Golubchik's avatar
      Merge branch '10.5' into 10.6 · b2187662
      Sergei Golubchik authored
      b2187662
    • Sergei Golubchik's avatar
      Merge branch '10.4' into 10.5 · 7970ac7f
      Sergei Golubchik authored
      7970ac7f
    • Andrei's avatar
      MDEV-28461 semisync-slave server recovery fails to rollback prepared transaction · 98ca71ab
      Andrei authored
      that is not in binlog.
      
      Post-crash recovery of --rpl-semi-sync-slave-enabled server
      failed to recognize a transaction in-doubt that needed rolled back.
      A prepared-but-not-in-binlog transaction gets committed instead
      to possibly create inconsistency with a master (e.g the way it was observed
      in the bug report).
      
      The semisync recovery is corrected now with initializing binlog coordinates
      of any transaction in-doubt to the maximum offset which is
      unreachable.
      In effect when a prepared transaction that is not found in binlog
      it will be decided to rollback because it's guaranteed to reside
      in a truncated tail area of binlog.
      
      Mtr tests are reinforced to cover the described scenario.
      98ca71ab
  5. 17 May, 2022 10 commits
  6. 16 May, 2022 8 commits
  7. 15 May, 2022 5 commits