1. 14 Mar, 2008 3 commits
  2. 07 Mar, 2008 2 commits
  3. 06 Mar, 2008 2 commits
  4. 04 Mar, 2008 1 commit
  5. 03 Mar, 2008 1 commit
  6. 28 Feb, 2008 2 commits
  7. 27 Feb, 2008 3 commits
  8. 26 Feb, 2008 2 commits
  9. 24 Feb, 2008 1 commit
  10. 23 Feb, 2008 1 commit
  11. 22 Feb, 2008 2 commits
    • joerg@trift2.'s avatar
      Merge trift2.:/MySQL/M50/mysql-5.0 · c93bb1bf
      joerg@trift2. authored
      into  trift2.:/MySQL/M50/push-5.0
      c93bb1bf
    • svoj@mysql.com/june.mysql.com's avatar
      BUG#13861 - START SLAVE UNTIL may stop 1 evnt too late if · fe3b1c8e
      svoj@mysql.com/june.mysql.com authored
                  log-slave-updates and circul repl
      
      Slave SQL thread may execute one extra event when there are events
      skipped by slave I/O thread (e.g. originated by the same server).
      Whereas it was requested not to do so by the UNTIL condition.
      
      This happens because we compare with the end position of previously
      executed event. This is fine when there are no skipped by slave I/O
      thread events, as end position of previous event equals to start
      position of to be executed event. Otherwise this position equals to
      start position of skipped event.
      
      This is fixed by:
      - reading the event to be executed before checking if the until condition
        is satisfied.
      - comparing the start position of the event to be executed. Since we do
        not have the start position available, we compute it by subtracting
        event length from end position (which is available).
      - if there are no events on the event queue at the slave sql starting
        time, that meet until condition, we stop immediately, as in this
        case we do not want to wait for next event.
      fe3b1c8e
  12. 21 Feb, 2008 8 commits
  13. 20 Feb, 2008 1 commit
    • davi@mysql.com/endora.local's avatar
      Bug#32265 Server returns different metadata if prepared statement is used · 04732055
      davi@mysql.com/endora.local authored
      Executing a prepared statement associated with a materialized
      cursor yields to the client a metadata packet with wrong table
      and database names. The problem was occurring because the server
      was sending the the name of the temporary table used by the cursor
      instead of the table name of the original table. The same problem
      occurs when selecting from views, in which case the table name was
      being sent and not the name of the view.
        
      The solution is to fill the list item from the temporary table but
      preserving the table and database names of the original fields. This
      is achieved by tweaking the Select_materialize to accept a pointer to
      the Materialized_cursor class which contains the item list to be filled.
      04732055
  14. 19 Feb, 2008 2 commits
  15. 18 Feb, 2008 4 commits
  16. 15 Feb, 2008 2 commits
  17. 14 Feb, 2008 3 commits