1. 10 Jun, 2010 4 commits
  2. 09 Jun, 2010 2 commits
  3. 08 Jun, 2010 14 commits
  4. 07 Jun, 2010 4 commits
  5. 05 Jun, 2010 1 commit
  6. 04 Jun, 2010 7 commits
  7. 03 Jun, 2010 5 commits
  8. 02 Jun, 2010 3 commits
    • Luis Soares's avatar
    • Luis Soares's avatar
    • Luis Soares's avatar
      BUG#53893: RBR: nullable unique key can lead to out-of-sync slave · 8ce9f9b3
      Luis Soares authored
      When using Unique Keys with nullable parts in RBR, the slave can
      choose the wrong row to update. This happens because a table with
      an unique key containing nullable parts cannot strictly guarantee 
      uniqueness. As stated in the manual, for all engines, a UNIQUE 
      index allows multiple NULL values for columns that can contain 
      NULL.
      
      We fix this at the slave by extending the checks before assuming
      that the row found through an unique index is is the correct
      one. This means that when a record (R) is fetched from the storage
      engine and a key that is not primary (K) is used, the server does 
      the following: 
      
       - If K is unique and has no nullable parts, it returns R;
       - Otherwise, if any field in the before image that is part of K
         is null do an index scan;
       - If there is no NULL field in the BI part of K, then return R.
      
      A side change: renamed the existing test case file and added a
      test case covering the changes in this patch.
      8ce9f9b3