1. 15 Jan, 2007 4 commits
    • dlenev@mockturtle.local's avatar
      Merge bk-internal.mysql.com:/home/bk/mysql-5.1-runtime · 6d65d121
      dlenev@mockturtle.local authored
      into  mockturtle.local:/home/dlenev/src/mysql-5.1-bg20390
      6d65d121
    • kostja@bodhi.local's avatar
      Merge bodhi.local:/opt/local/work/mysql-5.0-4968-pull-from-4.1 · 49532978
      kostja@bodhi.local authored
      into  bodhi.local:/opt/local/work/mysql-5.1-4968-null-merge
      49532978
    • dlenev@mockturtle.local's avatar
      Merge mockturtle.local:/home/dlenev/src/mysql-5.0-bg20390-2 · c0f6023a
      dlenev@mockturtle.local authored
      into  mockturtle.local:/home/dlenev/src/mysql-5.1-bg20390
      c0f6023a
    • dlenev@mockturtle.local's avatar
      Fix for bug#20390 "SELECT FOR UPDATE does not release locks · ab98cbc8
      dlenev@mockturtle.local authored
      of untouched rows in full table scans".
      
      SELECT ... FOR UPDATE/LOCK IN SHARE MODE statements as well as
      UPDATE/DELETE statements which were executed using full table
      scan were not releasing locks on rows which didn't satisfy
      WHERE condition.
      This bug surfaced in 5.0 and affected NDB tables. (InnoDB tables
      intentionally don't support such unlocking in default mode).
      
      This problem occured because code implementing join didn't call
      handler::unlock_row() for rows which didn't satisfy part of condition
      attached to this particular table/level of nested loop. So we solve
      the problem adding this call.
      Note that we already had this call in place in 4.1 but it was lost
      (actually not quite correctly placed) when we have introduced nested 
      joins.
      
      Also note that additional QA should be requested once this patch is
      pushed as interaction between handler::unlock_row() and many recent
      MySQL features such as subqueries, unions, views is not tested enough.
      ab98cbc8
  2. 12 Jan, 2007 9 commits
  3. 11 Jan, 2007 15 commits
  4. 10 Jan, 2007 12 commits