1. 04 Aug, 2010 1 commit
  2. 03 Aug, 2010 1 commit
  3. 02 Aug, 2010 1 commit
  4. 28 Jul, 2010 1 commit
  5. 23 Jul, 2010 1 commit
  6. 17 Jun, 2010 1 commit
  7. 15 Jun, 2010 6 commits
  8. 14 Jun, 2010 1 commit
  9. 10 Jun, 2010 1 commit
  10. 09 Jun, 2010 1 commit
  11. 07 Jun, 2010 1 commit
  12. 02 Jun, 2010 1 commit
  13. 01 Jun, 2010 7 commits
  14. 31 May, 2010 2 commits
  15. 28 May, 2010 3 commits
    • Jimmy Yang's avatar
      This is to fix a special case for the fix on bug #53592, where the · fc3449b1
      Jimmy Yang authored
      err_index could be not a member of the share structure or prebuilt
      structure passed from MySQL. For now, we resort to the traditional
      way of scanning index->table for the index number.
      fc3449b1
    • Mattias Jonsson's avatar
      merge · a82d45cc
      Mattias Jonsson authored
      a82d45cc
    • unknown's avatar
      Postfix for BUG#49741 · fc85a991
      unknown authored
      Add code to waiting for a set of errors.
      Add code to waiting for an error instead of waiting for io thread to stop, as
      after 'START SLAVE', the status of io thread is still not running.
      But it doesn't mean slave io thread encounters an error.
      fc85a991
  16. 27 May, 2010 4 commits
    • Dmitry Lenev's avatar
      A 5.1-only version of fix for bug #46947 "Embedded SELECT · 59d58220
      Dmitry Lenev authored
      without FOR UPDATE is causing a lock".
      
      SELECT statements with subqueries referencing InnoDB tables
      were acquiring shared locks on rows in these tables when they
      were executed in REPEATABLE-READ mode and with statement or
      mixed mode binary logging turned on.
      
      This was a regression which were introduced when fixing
      bug 39843.
      
      The problem was that for tables belonging to subqueries
      parser set TL_READ_DEFAULT as a lock type. In cases when
      statement/mixed binary logging at open_tables() time this
      type of lock was converted to TL_READ_NO_INSERT lock at
      open_tables() time and caused InnoDB engine to acquire
      shared locks on reads from these tables. Although in some
      cases such behavior was correct (e.g. for subqueries in
      DELETE) in case of SELECT it has caused unnecessary locking.
      
      This patch implements minimal version of the fix for the
      specific problem described in the bug-report which supposed
      to be not too risky for pushing into 5.1 tree.
      The 5.5 tree already contains a more appropriate solution
      which also addresses other related issues like bug 53921
      "Wrong locks for SELECTs used stored functions may lead
      to broken SBR".
      
      This patch tries to solve the problem by ensuring that
      TL_READ_DEFAULT lock which is set in the parser for
      tables participating in subqueries at open_tables()
      time is interpreted as TL_READ_NO_INSERT or TL_READ.
      TL_READ is used only if we know that this is a SELECT
      and that this particular table is not used by a stored
      function.
      
      Test coverage is added for both InnoDB and MyISAM.
      
      This patch introduces an "incompatible" change in locking
      scheme for subqueries used in SELECT ... FOR UPDATE and
      SELECT .. IN SHARE MODE.
      
      In 4.1 (as well as in 5.0 and 5.1 before fix for bug 39843)
      the server would use a snapshot InnoDB read for subqueries
      in SELECT FOR UPDATE and SELECT .. IN SHARE MODE statements,
      regardless of whether the binary log is on or off.
      
      If the user required a different type of read (i.e. locking
      read), he/she could request so explicitly by providing FOR
      UPDATE/IN SHARE MODE clause for each individual subquery.
      
      The patch for bug 39843 broke this behaviour (which was not
      documented or tested), and started to use locking reads for
      all subqueries in SELECT ... FOR UPDATE/IN SHARE MODE.
      This patch restores 4.1 behaviour.
      
      This patch should be mostly null-merged into 5.5 tree.
      
      mysql-test/include/check_concurrent_insert.inc:
        Added auxiliary script which allows to check if statement
        reading table allows concurrent inserts in it.
      mysql-test/include/check_no_concurrent_insert.inc:
        Added auxiliary script which allows to check that statement
        reading table doesn't allow concurrent inserts in it.
      mysql-test/include/check_no_row_lock.inc:
        Added auxiliary script which allows to check if statement
        reading table doesn't take locks on its rows.
      mysql-test/include/check_shared_row_lock.inc:
        Added auxiliary script which allows to check if statement
        reading table takes shared locks on some of its rows.
      mysql-test/r/bug39022.result:
        After bug #46947 'Embedded SELECT without FOR UPDATE is
        causing a lock' was fixed test case for bug 39022 has to
        be adjusted in order to trigger execution path on which
        original problem was encountered.
      mysql-test/r/innodb_mysql_lock2.result:
        Added coverage for handling of locking in various cases when
        we read data from InnoDB tables (includes test case for
        bug #46947 'Embedded SELECT without FOR UPDATE is causing a
        lock').
      mysql-test/r/lock_sync.result:
        Added coverage for handling of locking in various cases when
        we read data from MyISAM tables.
      mysql-test/t/bug39022.test:
        After bug #46947 'Embedded SELECT without FOR UPDATE is
        causing a lock' was fixed test case for bug 39022 has to
        be adjusted in order to trigger execution path on which
        original problem was encountered.
      mysql-test/t/innodb_mysql_lock2.test:
        Added coverage for handling of locking in various cases when
        we read data from InnoDB tables (includes test case for
        bug #46947 'Embedded SELECT without FOR UPDATE is causing a
        lock').
      mysql-test/t/lock_sync.test:
        Added coverage for handling of locking in various cases when
        we read data from MyISAM tables.
      sql/mysql_priv.h:
        Function read_lock_type_for_table() now takes pointers to
        LEX and TABLE_LIST elements as its arguments since to
        correctly determine lock type it needs to know what
        statement is being performed and whether table element for
        which lock type to be determined belongs to prelocking list.
      sql/sql_base.cc:
        Changed read_lock_type_for_table() to return a weak TL_READ
        type of lock in cases when we are executing SELECT (and so
        won't update tables directly) and table doesn't belong to
        statement's prelocking list and thus can't be used by a
        stored function. It is OK to do so since in this case table
        won't be used by statement or function call which will be
        written to the binary log, so serializability requirements
        for it can be relaxed.
        One of results from this change is that SELECTs on InnoDB
        tables no longer takes shared row locks for tables which
        are used in subqueries (i.e. bug #46947 is fixed).
        Another result is that for similar SELECTs on MyISAM tables
        concurrent inserts are allowed.
        In order to implement this change signature of
        read_lock_type_for_table() function was changed to
        take pointers to LEX and TABLE_LIST objects.
      sql/sql_update.cc:
        Function read_lock_type_for_table() now takes pointers to
        LEX and TABLE_LIST elements as its arguments since to
        correctly determine lock type it needs to know what
        statement is being performed and whether table element for
        which lock type to be determined belongs to prelocking list.
      59d58220
    • Inaam Rana's avatar
      Fix the printout in for long semaphore waits to not · 40d60c89
      Inaam Rana authored
      list a thread doing a wait_ex as an s-lock waiter.
      40d60c89
    • Sergey Glukhov's avatar
      Bug#52005 'JOIN_TAB->dependent' may be incorrectly propageted for multilevel outer joins · 892a96e7
      Sergey Glukhov authored
      There are two problems:
      1. In simplify_joins function we calculate table dependencies. If STRAIGHT_JOIN hint
      is used for whole SELECT we do not count it and as result some dependendecies
      might be lost. It leads to incorrect table order which is returned by
      join_tab_cmp_straight() function.
      2. make_join_statistics() calculate the transitive closure for relations a particular
      JOIN_TAB is 'dependent on'.
      We aggregate the dependent table_map of a JOIN_TAB by adding dependencies from other
      tables which we depend on. However, this may also cause new dependencies to be
      available after we have completed processing a certain JOIN_TAB.
      Both these problems affect condition pushdown and as result condition might be pushed
      into wrong table which leads to crash or even omitted which leads to wrong result.
      The fix:
      1. Use modified 'transitive closure' algorithm provided by Ole John Aske
      2. Update table dependences in simplify_joins according to 
         global STRAIGHT_JOIN hint.
      Note: the patch also fixes bugs 46091 & 51492
      
      
      mysql-test/r/join_outer.result:
        test case
      mysql-test/t/join_outer.test:
        test case
      sql/sql_select.cc:
        1. Use modified 'transitive closure' algorithm provided by Ole John Aske
        2. Update table dependences in simplify_joins according to 
           global STRAIGHT_JOIN hint.
      892a96e7
    • Alexey Kopytov's avatar
      Automerge. · 96b0746f
      Alexey Kopytov authored
      96b0746f
  17. 26 May, 2010 4 commits
  18. 25 May, 2010 3 commits
    • Ramil Kalimullin's avatar
      Manual merge. · d79a1a74
      Ramil Kalimullin authored
      d79a1a74
    • Alexey Kopytov's avatar
      Bug #53830: !table || (!table->read_set || · 48552797
      Alexey Kopytov authored
                   bitmap_is_set(table->read_set, field_index))
      
      UPDATE on an InnoDB table modifying the same index that is used
      to satisfy the WHERE condition could trigger a debug assertion
      under some circumstances.
      
      Since for engines with the HA_PRIMARY_KEY_IN_READ_INDEX flag
      set results of an index scan on a secondary index are appended
      by the primary key value, if a query involves only columns from
      the primary key and a secondary index, the latter is considered
      to be covering.
      
      That tricks mysql_update() to mark for reading only columns
      from the secondary index when it does an index scan to retrieve
      rows to update in case a part of that key is also being
      updated. However, there may be other columns in WHERE that are
      part of the primary key, but not the secondary one.
      
      What we actually want to do in this case is to add index
      columns to the existing WHERE columns bitmap rather than
      replace it.
      
      mysql-test/r/innodb_mysql.result:
        Test case for bug #53830.
      mysql-test/t/innodb_mysql.test:
        Test case for bug #53830.
      sql/sql_update.cc:
        Add index columns to the read_set bitmap, don't replace it.
      sql/table.cc:
        Added a new add_read_columns_used_by_index() function to 
        st_table.
      sql/table.h:
        Added a new add_read_columns_used_by_index() function to 
        st_table.
      48552797
    • Vasil Dimov's avatar
      5dceb98d