1. 14 Jan, 2011 1 commit
    • Sven Sandberg's avatar
      BUG#59063: rpl_migration_crash_safe fails on Windows · d3ea6f9b
      Sven Sandberg authored
      Backported the fix to 5.1.
      Problem: the auxiliary test files rpl_start_server.inc and rpl_stop_server.inc
      write a file that is later read by mtr. The bug was that the file was written
      with platform-dependent newline terminators, i.e., \r\n on windows, whereas mtr
      only understands \n.
      Fix: write the file so that it uses \n on all platforms.
      d3ea6f9b
  2. 13 Jan, 2011 5 commits
  3. 12 Jan, 2011 6 commits
    • Bjorn Munch's avatar
      merge from 5.1-mtr · f23725f2
      Bjorn Munch authored
      f23725f2
    • Luis Soares's avatar
      BUG#59177: mysqlbinlog_row_big fails on Windows with out of memory · 51c6f8eb
      Luis Soares authored
            
      The test case fails with out of memory while updating a table
      with several multi-megabytes sized rows. This can probably be too
      exhausting for PB2 env.
            
      The quick fix here is to reduce the size of the biggest
      row (256MB) so that it becomes a little smaller (64MB).
      51c6f8eb
    • Bjorn Munch's avatar
      merge from 5.1 · 06c43adc
      Bjorn Munch authored
      06c43adc
    • Dmitry Lenev's avatar
      Fix for bug #58499 "DEFINER-security view selecting from · 94fbedd3
      Dmitry Lenev authored
      INVOKER-security view access check wrong".
      
      When privilege checks were done for tables used from an 
      INVOKER-security view which in its turn was used from 
      a DEFINER-security view connection's active security
      context was incorrectly used instead of security context
      with privileges of the second view's creator.
      
      This meant that users which had enough rights to access
      the DEFINER-security view and as result were supposed to 
      be able successfully access it were unable to do so in 
      cases when they didn't have privileges on underlying tables 
      of the INVOKER-security view.
      
      This problem was caused by the fact that for INVOKER-security
      views TABLE_LIST::security_ctx member for underlying tables
      were set to 0 even in cases when particular view was used from 
      another DEFINER-security view. This meant that when checks of
      privileges on these underlying tables was done in
      setup_tables_and_check_access() active connection security 
      context was used instead of context corresponding to the 
      creator of caller view.
      
      This fix addresses the problem by ensuring that underlying
      tables of an INVOKER-security view inherit security context
      from the view and thus correct security context is used for
      privilege checks on underlying tables in cases when such view 
      is used from another view with DEFINER-security.
      94fbedd3
    • Alexey Botchkov's avatar
      Bug #57321 crashes and valgrind errors from spatial types · e073e2c0
      Alexey Botchkov authored
              Item_func_spatial_collection::fix_length_and_dec didn't call parent's method, so
              the maybe_null was set to '0' after it. But in this case the result was
              just NULL, that caused wrong behaviour.
      
      per-file comments:
        mysql-test/r/gis.result
      Bug #57321 crashes and valgrind errors from spatial types 
              test result updated.
      
        mysql-test/t/gis.test
      Bug #57321 crashes and valgrind errors from spatial types 
              test case added.
        sql/item_geofunc.h
      Bug #57321 crashes and valgrind errors from spatial types 
              Item_func_geometry::fix_length_and_dec() called in
              Item_func_spatial_collection::fix_length_and_dec().
      e073e2c0
    • Martin Hansson's avatar
      Bug#58207: invalid memory reads when using default column value and · fc42cbac
      Martin Hansson authored
      tmptable needed
      
      The function DEFAULT() works by modifying the the data buffer pointers (often
      referred to as 'record' or 'table record') of its argument. This modification
      is done during name resolution (fix_fields().) Unfortunately, the same
      modification is done when creating a temporary table, because default values
      need to propagate to the new table.
      
      Fixed by skipping the pointer modification for fields that are arguments to
      the DEFAULT function.
      fc42cbac
  4. 11 Jan, 2011 7 commits
  5. 10 Jan, 2011 3 commits
  6. 08 Jan, 2011 2 commits
  7. 07 Jan, 2011 6 commits
  8. 06 Jan, 2011 3 commits
  9. 05 Jan, 2011 4 commits
  10. 04 Jan, 2011 3 commits
    • kevin.lewis@oracle.com's avatar
      43818 - Patch for mysql-5.1-innodb · 66d50854
      kevin.lewis@oracle.com authored
      Avoid handler::info() call for three Information Schema tables;
      TABLE_CONSTRAINTS, KEY_COLUMN_USAGE, & REFERENTIAL_CONTRAINTS
      66d50854
    • Jon Olav Hauglid's avatar
      Bug #50619 assert in handler::update_auto_increment · 78df8c4f
      Jon Olav Hauglid authored
      This assert could be triggered if -1 was inserted into
      an auto increment column by a statement writing more than
      one row.
      
      Unless explicitly given, an interval of auto increment values
      is generated when a statement first needs an auto increment
      value. The triggered assert checks that the auto increment
      counter is equal to or higher than the lower bound of this
      interval.
      
      Generally, the auto increment counter starts at 1 and is
      incremented by 1 each time it is used. However, inserting an
      explicit value into the auto increment column, sets the auto
      increment counter to this value + 1 if this value is higher
      than the current value of the auto increment counter.
      
      This bug was triggered if the explicit value was -1. Since the
      value was converted to unsigned before any comparisons were made,
      it was found to be higher than the current vale of the auto
      increment counter and the counter was set to -1 + 1. This value
      was below the reserved interval and caused the assert to be
      triggered the next time the statement tried to write a row.
      
      With the patch for Bug#39828, this bug is no longer repeatable.
      Now, -1 + 1 is detected as an "overflow" which causes the auto
      increment counter to be set to ULONGLONG_MAX. This avoids hitting
      the assert for the next insert and causes a new interval of
      auto increment values to be generated. This resolves the issue.
      
      This patch therefore only contains a regression test and no code
      changes. Test case added to auto_increment.test.
      78df8c4f
    • Mattias Jonsson's avatar
      merge · 16994abf
      Mattias Jonsson authored
      16994abf