1. 19 Oct, 2010 13 commits
    • Davi Arnaut's avatar
      9be9ad7b
    • Davi Arnaut's avatar
      Bug#45288: pb2 returns a lot of compilation warnings · 7406b38e
      Davi Arnaut authored
      Ensure that fdatasync is properly declared as on Mac OS X, the
      function is available but there is no prototype. Also, port a
      fix for a warning from the InnoDB plugin over to the builtin. 
      
      configure.in:
        Check that fdatasync is declared.
      mysys/my_sync.c:
        Use fdatasync only if it is declared.
      storage/innobase/include/ut0dbg.h:
        Port over from the plugin a fix for a warning.
      7406b38e
    • Davi Arnaut's avatar
      a7c93338
    • Davi Arnaut's avatar
      Bug#45288: pb2 returns a lot of compilation warnings on linux · be170c21
      Davi Arnaut authored
      Tag unused arguments.
            
      Approved by: Marko (via IRC)
      be170c21
    • Davi Arnaut's avatar
      Bug#45288: pb2 returns a lot of compilation warnings on linux · 8875c2c2
      Davi Arnaut authored
      Tag unused arguments.
      
      Approved by: Marko (via IRC)
      8875c2c2
    • Davi Arnaut's avatar
      Bug#45288: pb2 returns a lot of compilation warnings on linux · 18371055
      Davi Arnaut authored
      Fix assorted compiler warnings on Mac OS X.
      
      BUILD/SETUP.sh:
        Remove -Wctor-dtor-privacy flag to workaround a GCC bug that
        causes it to not properly detect that implicitly generated
        constructors are always public.
      cmd-line-utils/readline/terminal.c:
        tgetnum and tgetflag might not take a const string argument.
      mysys/my_gethostbyname.c:
        Tag unused arguments.
      mysys/my_sync.c:
        Tag unused arguments.
      18371055
    • Magne Mahre's avatar
      Bug #46941 crash with lower_case_table_names=2 and foreign key · 95d91c0f
      Magne Mahre authored
                 data dictionary confusion
      
      On file systems with case insensitive file names, and
      lower_case_table_names set to '2', the server could crash
      due to a table definition cache inconsistency.  This is 
      the default setting on MacOSX, but may also be set and
      used on MS Windows.
      
      The bug is caused by using two different strategies for
      creating the hash key for the table definition cache, resulting
      in failure to look up an entry which is present in the cache,
      or failure to delete an existing entry.  One strategy was to
      use the real table name (with case preserved), and the other
      to use a normalized table name (i.e a lower case version).
      
      This is manifested in two cases.  One is  during 'DROP DATABASE', 
      where all known files are removed.  The removal from
      the table definition cache is done via a generated list of
      TABLE_LIST with keys (wrongly) created using the case preserved 
      name.  The other is during CREATE TABLE, where the cache lookup
      is also (wrongly) based on the case preserved name.
         
      The fix was to use only the normalized table name when
      creating hash keys.
      
      
      sql/sql_db.cc:
        Normalize table name (i.e lower case it)
      sql/sql_table.cc:
        table_name contains the normalized name
        alias contains the real table name
      95d91c0f
    • Jon Olav Hauglid's avatar
      Bug #57274 SET GLOBAL debug crashes on Solaris in embedded server mode · 4776282b
      Jon Olav Hauglid authored
                 (variables_debug fails)
      
      The problem was that "SET GLOBAL debug" could cause a crash on Solaris.
      The crash happened if the server failed to open the trace file given in 
      the "SET GLOBAL debug" statement. This caused an error message to be
      printed to stderr containing the process name. However, printing to
      stderr crashed the server since the pointer to the process name had
      not been initialized.
      
      This patch fixes the problem by initializing the process name 
      properly when doing "SET GLOBAL debug".
      
      No test case added as this bug was repeatable with existing test
      coverage in variables_debug.test.
      4776282b
    • Tor Didriksen's avatar
      af665ea9
    • Tor Didriksen's avatar
      Bug #57203 Assertion `field_length <= 255' failed. · a6df37db
      Tor Didriksen authored
      After the fix for
      Bug #55077 Assertion failed: width > 0 && to != ((void *)0), file .\dtoa.c
      we no longer try to allocate a string of length 'field_length'
      so the asserts are relevant only for ZEROFILL columns.
      
      
      
      mysql-test/r/select.result:
        Add test case for Bug#57203
      mysql-test/t/select.test:
        Add test case for Bug#57203
      sql/field.cc:
        Rewrite the DBUG_ASSERTS on field_length.
      a6df37db
    • Magne Mahre's avatar
      Merge from mysql-5.1-bugteam to mysql-5.5-bugteam · b61b7852
      Magne Mahre authored
      Only test case is merged, as the fix was already
      present in 5.5 code
      b61b7852
    • Jon Olav Hauglid's avatar
      Merge from mysql-5.1-bugteam to mysql-5.5-bugteam · 87b91752
      Jon Olav Hauglid authored
      No conflicts
      87b91752
    • Tor Didriksen's avatar
  2. 18 Oct, 2010 7 commits
  3. 16 Oct, 2010 2 commits
    • unknown's avatar
      Manual merge · c20cbe5b
      unknown authored
      c20cbe5b
    • unknown's avatar
      Bug#56118 STOP SLAVE does not wait till trx with CREATE TMP TABLE ends, · 211552cc
      unknown authored
                replication aborts
      
      When recieving a 'SLAVE STOP' command, slave SQL thread will roll back the
      transaction and stop immidiately if there is only transactional table updated,
      even through 'CREATE|DROP TEMPOARY TABLE' statement are in it. But These
      statements can never be rolled back. Because the temporary tables to the user
      session mapping remain until 'RESET SLAVE', Therefore it will abort SQL thread
      with an error that the table already exists or doesn't exist, when it restarts
      and executes the whole transaction again.
      
      After this patch, SQL thread always waits till the transaction ends and then stops,
      if 'CREATE|DROP TEMPOARY TABLE' statement are in it.
      
      mysql-test/extra/rpl_tests/rpl_stop_slave.test:
        Auxiliary file which is used to test this bug.
      mysql-test/suite/rpl/t/rpl_stop_slave.test:
        Test case for this bug.
      sql/slave.cc:
        Checking if OPTION_KEEP_LOG is set. If it is set, SQL thread should wait
        until the transaction ends.
      sql/sql_parse.cc:
        Add a debug point for testing this bug.
      211552cc
  4. 14 Oct, 2010 2 commits
    • Alexander Nozdrin's avatar
      A patch for Bug#48874 (Test "is_triggers" fails because of wrong charset info). · 650e4c25
      Alexander Nozdrin authored
      The thing is that the following attributes are fixed (remembered) when a trigger
      is created:
        - character_set_client
        - character_set_results
        - collation_connection
      
      There are two triggers created in mysql-test/include/mtr_warnings.sql.
      They were created using "current default" character set / collation.
      is_triggers.test shows definition of these triggers including recorded
      character set information.
      
      The problem was that if "current default" changed, the recorded character
      set information was not accurate.
      
      There might be two ways to fix that:
        a) update is_triggers.test so that it does not put character-set information
           into result-file;
        b) update mtr_warnings.sql so that the triggers are created using
           hard-coded character sets.
      
      This patch implements option b).
      650e4c25
    • Davi Arnaut's avatar
      Bug#56096: STOP SLAVE hangs if executed in parallel with user sleep · 1d43e72a
      Davi Arnaut authored
      The root of the problem is that to interrupt a slave SQL thread
      wait, the STOP SLAVE implementation uses thd->awake(THD::NOT_KILLED).
      This appears as a spurious wakeup (e.g. from a sleep on a
      condition variable) to the code that the slave SQL thread is
      executing at the time of the STOP. If the code is not written
      to be spurious-wakeup safe, unexpected behavior can occur. For
      the reported case, this problem led to an infinite loop around
      the interruptible_wait() function in item_func.cc (SLEEP()
      function implementation).  The loop was not being properly
      restarted and, consequently, would not come to an end. Since the
      SLEEP function sleeps on a timed event in order to be killable
      and to perform periodic checks until the requested time has
      elapsed, the spurious wake up was causing the requested sleep
      time to be reset every two seconds.
      
      The solution is to calculate the requested absolute time only
      once and to ensure that the thread only sleeps until this
      time is elapsed. In case of a spurious wake up, the sleep is
      restarted using the previously calculated absolute time. This
      restores the behavior present in previous releases. If a slave
      thread is executing a SLEEP function, a STOP SLAVE statement
      will wait until the time requested in the sleep function
      has elapsed.
      
      mysql-test/extra/rpl_tests/rpl_start_stop_slave.test:
        Add test case for Bug#56096.
      mysql-test/suite/rpl/r/rpl_stm_start_stop_slave.result:
        Add test case result for Bug#56096.
      sql/item_func.cc:
        Reorganize interruptible_wait into a class so that the absolute
        time can be preserved across calls to the wait function. This
        allows the sleep to be properly restarted in the presence of
        spurious wake ups, including those generated by a STOP SLAVE.
      1d43e72a
  5. 13 Oct, 2010 8 commits
  6. 12 Oct, 2010 3 commits
  7. 11 Oct, 2010 5 commits