1. 04 Feb, 2010 1 commit
    • Luis Soares's avatar
      BUG#50451: rpl_loaddata_concurrent fails sporadically · 635a83cc
      Luis Soares authored
      When using MyIsam tables and processing concurrent DML
      statements, the server may be sending back an OK to the client
      before actually finishing the transaction commit procedure. This
      has been reported before in BUG@37521 and BUG@29334.
      
      This particular test case gets affected, because it performs the
      following sequence:
        
        connect (conn2, ...)
        connection conn2;
        LOAD DATA CONCURRENT ...
        disconnect (conn2, ...)
        connection master;
        sync_slave_with_master
        diff_tables
      
      At this point diff_tables may report difference in the table
      content (the master seems to be missing the conn2 rows). 
      
      To workaround this MyISAM concurrent DML statements issue and
      make this test case deterministic, we wait on conn2 until the
      rows inserted show up in the table. After this the test case
      proceeds as normally would before this patch.
      635a83cc
  2. 02 Feb, 2010 1 commit
    • Kent Boortz's avatar
      Changes to be able to create source TAR packages with longer · 480663e4
      Kent Boortz authored
      path names than 99 characters, using the USTAR format of the
      resulting source TAR.
      
      To be able to specify the use of USTAR when creating the source
      TAR, we needed both to update the GNU autotools version requirements
      slightly, and update the initiation of the tools to use more
      modern constructs.
      480663e4
  3. 21 Jan, 2010 1 commit
    • Georgi Kodinov's avatar
      Bug #50276: Security flaw in INFORMATION_SCHEMA.TABLES · 2c44919b
      Georgi Kodinov authored
      check_access() returning false for a database does not
      guarantee that the access is granted to it.
      This wrong condition in filling the INFORMATION_SCHEMA
      tables causes extra tables to be returned to the user
      even if he has no rights to see them.
      Fixed by correcting the condition.
      2c44919b
  4. 02 Feb, 2010 5 commits
    • Georgi Kodinov's avatar
      Bug #49445: Assertion failed: 0, file .\item_row.cc, line 55 with · 4cfda7fd
      Georgi Kodinov authored
        fulltext search and row op.
      
      The search for fulltext indexes is searching for some special 
      predicate layouts. While doing so it's not checking for the number
      of columns of the expressions it tries to calculate.
      And since row expressions can't return a single scalar value there
      was a crash.
      Fixed by checking if the expressions are scalar (in addition to 
      being constant) before calling Item::val_xxx() methods.
      4cfda7fd
    • Magne Mahre's avatar
      Cleanup fix for WL#5154 that splits commands handling for · 632cf4c5
      Magne Mahre authored
      --default-character-set and --character-set-server such
      that only the first will give a deprecation warning.
      Apart from that, the two options should do the same.
      632cf4c5
    • Alexander Nozdrin's avatar
      Revert a patch for Bug#48231, which introduced valgrind warnings. · f392edda
      Alexander Nozdrin authored
      Original revision:
      ------------------------------------------------------------
      revision-id: li-bing.song@sun.com-20100130124925-o6sfex42b6noyc6x
      parent: joro@sun.com-20100129145427-0n79l9hnk0q43ajk
      committer: <Li-Bing.Song@sun.com>
      branch nick: mysql-5.1-bugteam
      timestamp: Sat 2010-01-30 20:49:25 +0800
      message:
        Bug #48321  CURRENT_USER() incorrectly replicated for DROP/RENAME USER;
                    REVOKE/GRANT; ALTER EVENT.
        
        The following statements support the CURRENT_USER() where a user is needed.
          DROP USER 
          RENAME USER CURRENT_USER() ...
          GRANT ... TO CURRENT_USER()
          REVOKE ... FROM CURRENT_USER()
          ALTER DEFINER = CURRENT_USER() EVENT
        but, When these statements are binlogged, CURRENT_USER() just is binlogged
        as 'CURRENT_USER()', it is not expanded to the real user name. When slave 
        executes the log event, 'CURRENT_USER()' is expand to the user of slave 
        SQL thread, but SQL thread's user name always NULL. This breaks the replication.
        
        After this patch, All above statements are rewritten when they are binlogged.
        The CURRENT_USER() is expanded to the real user's name and host.
      ------------------------------------------------------------
      f392edda
    • Davi Arnaut's avatar
    • Georgi Kodinov's avatar
      be89d30f
  5. 01 Feb, 2010 3 commits
  6. 30 Jan, 2010 1 commit
    • 's avatar
      Bug #48321 CURRENT_USER() incorrectly replicated for DROP/RENAME USER; · 788c28ac
      authored
                  REVOKE/GRANT; ALTER EVENT.
      
      The following statements support the CURRENT_USER() where a user is needed.
        DROP USER 
        RENAME USER CURRENT_USER() ...
        GRANT ... TO CURRENT_USER()
        REVOKE ... FROM CURRENT_USER()
        ALTER DEFINER = CURRENT_USER() EVENT
      but, When these statements are binlogged, CURRENT_USER() just is binlogged
      as 'CURRENT_USER()', it is not expanded to the real user name. When slave 
      executes the log event, 'CURRENT_USER()' is expand to the user of slave 
      SQL thread, but SQL thread's user name always NULL. This breaks the replication.
      
      After this patch, All above statements are rewritten when they are binlogged.
      The CURRENT_USER() is expanded to the real user's name and host.
      788c28ac
  7. 29 Jan, 2010 3 commits
  8. 28 Jan, 2010 1 commit
  9. 29 Jan, 2010 2 commits
  10. 28 Jan, 2010 3 commits
  11. 27 Jan, 2010 9 commits
  12. 26 Jan, 2010 3 commits
  13. 25 Jan, 2010 2 commits
    • Andrei Elkin's avatar
      Bug #47142 "slave start until" stops 1 event too late in 4.1 to 5.0 replication · 1c0056b3
      Andrei Elkin authored
      When replicating from 4.1 master to 5.0 slave START SLAVE UNTIL can stop too late.
      The necessary in calculating of the beginning of an event the event's length
      did not correspond to the master's genuine information at the event's execution time.
      That piece of info was changed at the event's relay-logging due to binlog_version<4 event
      conversion by IO thread.
      
      Fixed with storing the master genuine Query_log_event size into a new status
      variable at relay-logging of the event. The stored info is extacted at the event
      execution and participate further to caclulate the correct start position of the event
      in the until-pos stopping routine.
      The new status variable's algorithm will be only active when the event comes
      from the master of version < 5.0 (binlog_version < 4).
      1c0056b3
    • 's avatar
      Manual merge with Conflicts: · 8a66b424
      authored
      sql_udf.cc
      8a66b424
  14. 24 Jan, 2010 1 commit
  15. 22 Jan, 2010 4 commits