1. 20 Aug, 2013 3 commits
    • unknown's avatar
      new format length calculation check added. · 9a28e433
      unknown authored
      9a28e433
    • unknown's avatar
      bMDEV-4906: When event apply fails, next SQL thread start errorneously commits... · 0903a40d
      unknown authored
      bMDEV-4906: When event apply fails, next SQL thread start errorneously commits the failing GTID to gtid_slave_pos
      
      When a GTID event is executed, we remember the contained GTID position so that
      when we have applied the entire event group we can commit it to
      gtid_slave_pos.
      
      However, if the event group fails to apply due to some error and the SQL
      thread aborts, the code did not correctly clear the remembered GTID. Thus,
      when SQL thread was restarted, the old GTID of the failing event group was
      incorrectly updated to gtid_slave_pos when the initial rotate event was
      executed, corrupting the GTID position.
      0903a40d
    • unknown's avatar
      merge 5.5 -> 10.0-base · 35b28836
      unknown authored
      35b28836
  2. 19 Aug, 2013 1 commit
    • unknown's avatar
      · dafa4582
      unknown authored
      mysql-test/r/func_set.result:
        merge
      dafa4582
  3. 18 Aug, 2013 1 commit
    • Igor Babaev's avatar
      Fixed bug mdev-4918. · 7c85205d
      Igor Babaev authored
      The function SELECT_LEX::mark_const_derived() must take into account that
      in DELETE ... RETURNING join == NULL.
      7c85205d
  4. 16 Aug, 2013 1 commit
    • unknown's avatar
      MDEV-4820: Empty master does not give error for slave GTID position that does... · f0deff86
      unknown authored
      MDEV-4820: Empty master does not give error for slave GTID position that does not exist in the binlog
      
      The main bug here was the following situation:
      
      Suppose we set up a completely new master2 as an extra multi-master to an
      existing slave that already has a different master1 for domain_id=0. When the
      slave tries to connect to master2, master2 will not have anything that slave
      requests in domain_id=0, but that is fine as master2 is supposedly meant to
      serve eg. domain_id=1. (This is MDEV-4485).
      
      But suppose that master2 then actually starts sending events from
      domain_id=0. In this case, the fix for MDEV-4485 was incomplete, and the code
      would fail to give the error that the position requested by the slave in
      domain_id=0 was missing from the binlogs of master2. This could lead to lost
      events or completely wrong replication.
      
      The patch for this bug fixes this issue.
      
      In addition, it cleans up the code a bit, getting rid of the fake_gtid_hash in
      the code. And the error message when slave and master have diverged due to
      alternate future is clarified, as requested in the bug description.
      
      f0deff86
  5. 12 Aug, 2013 2 commits
  6. 08 Aug, 2013 5 commits
  7. 06 Aug, 2013 2 commits
  8. 05 Aug, 2013 7 commits
  9. 01 Aug, 2013 1 commit
  10. 31 Jul, 2013 2 commits
  11. 29 Jul, 2013 1 commit
    • Vladislav Vaintroub's avatar
      MDEV-4815 - allow multiple mysql_server_init() / mysql_server_end() in the... · 3ef0157d
      Vladislav Vaintroub authored
      MDEV-4815 - allow multiple  mysql_server_init() / mysql_server_end() in the same process, for embedded library.
      
      - Reset  static variables that are used to signal "init done"  for DBUG, in dbug_end()
      - Set string server variables to NULL after memory for the value is freed - avoids double free()
      - fix DBUG_ASSERTs that happened during reinitialization.
      3ef0157d
  12. 25 Jul, 2013 1 commit
    • Sergey Petrunya's avatar
      MDEV-4687: impossible where with < operation, but =-5 return one row · 9a780a59
      Sergey Petrunya authored
      - Let _ma_record_pos() set SEARCH_PART_KEY when doing a search on
        a prefix of a [unique] key.  Otherwise, _ma_search_pos() would 
        find the first key equal to search key, and assume it is also 
        the last one, which will make a wrong estimate of key's position.
      
        A wrong key position may cause min_pos > max_pos and records_in_range()
        will return 0, which will make the optimizer think it's an impossible 
        range while in fact it is not.
      9a780a59
  13. 19 Jul, 2013 1 commit
  14. 18 Jul, 2013 1 commit
  15. 17 Jul, 2013 3 commits
  16. 16 Jul, 2013 8 commits