1. 11 Dec, 2007 1 commit
  2. 10 Dec, 2007 5 commits
  3. 07 Dec, 2007 1 commit
    • thek@adventure.(none)'s avatar
      Bug #27440 read_only allows create and drop database · 392cc185
      thek@adventure.(none) authored
      When read_only option was enabled, a user without SUPER privilege could
      perform CREATE DATABASE and DROP DATABASE operations.
      
      This patch adds a check to make sure this isn't possible. It also attempts to 
      simplify the logic used to determine if relevant tables are updated,
      making it more human readable.
      392cc185
  4. 05 Dec, 2007 2 commits
  5. 04 Dec, 2007 2 commits
  6. 30 Nov, 2007 6 commits
    • davi@endora.local's avatar
      Merge bk-internal.mysql.com:/home/bk/mysql-5.1-runtime · af039c53
      davi@endora.local authored
      into  mysql.com:/Users/davi/mysql/mysql-5.1-runtime
      af039c53
    • davi@endora.local's avatar
      Merge mysql.com:/Users/davi/mysql/bugs/22312-5.1 · 7bdb3219
      davi@endora.local authored
      into  mysql.com:/Users/davi/mysql/mysql-5.1-runtime
      7bdb3219
    • anozdrin/alik@ibm.'s avatar
      A patch for BUG#32148: killing a query may be ineffective. · 8377c71f
      anozdrin/alik@ibm. authored
      The problem was that THD::killed was reset after a command was
      read from the socket, but before it was actually handled. That lead
      to a race: if another KILL statement was issued for this connection
      in the middle of reading from the socket and processing a command,
      THD::killed state would be cleaned.
      
      The fix is to move this cleanup into net_send_error() function.
      
      A sample test case exists in binlog_killed.test:
        - connection 1: start a new transaction on table t1;
        - connection 2: send query to the server (w/o waiting for the
          result) to update data in table t1 -- this query will be blocked
          since there is unfinished transaction;
        - connection 1: kill query in connection 2 and finish the transaction;
        - connection 2: get result of the previous query -- it should be
          the "query-killed" error.
      
      This test however contains race condition, which can not be fixed
      with the current protocol: there is no way to guarantee, that the
      server will receive and start processing the query in connection 2
      (which is intended to get blocked) before the KILL command (sent in
      the connection 1) will arrive. In other words, there is no way to
      ensure that the following sequence will not happen:
      
        - connection 1: start a new transaction on table t1;
        - connection 1: kill query in connection 2 and finish the transaction;
        - connection 2: send query to the server (w/o waiting for the
          result) to update data in table t1 -- this query will be blocked
          since there is unfinished transaction;
        - connection 2: get result of the previous query -- the query will
          succeed.
      
      So, there is no test case for this bug, since it's impossible
      to write a reliable test case under the current circumstances.
      8377c71f
    • anozdrin/alik@ibm.'s avatar
      BUG#32723 (grant3.test fails) can not be reproduced. · 609a1d0d
      anozdrin/alik@ibm. authored
      Enabling the test case.
      609a1d0d
    • davi@mysql.com/endora.local's avatar
      Bug#22312 Syntax error in expression with INTERVAL() · ee9bafc1
      davi@mysql.com/endora.local authored
      Parser rejects valid INTERVAL() expressions when associated with
      arithmetic operators. The problem is the way in which the expression
      and interval grammar rules were organized caused shift/reduce conflicts.
      
      The solution is to tweak the interval rules to avoid shift/reduce
      conflicts by removing the broken interval_expr rule and explicitly
      specify it's content where necessary.
      
      Original fix by Davi Arnaut, revised and improved rules by Marc Alff
      ee9bafc1
    • anozdrin/alik@ibm.'s avatar
      A test case for BUG#26676: VIEW using old table schema in a session. · a1666e06
      anozdrin/alik@ibm. authored
      The following clarification should be made in The Manual:
      
      Standard SQL is quite clear that, if new columns are added
      to a table after a view on that table is created with
      "select *", the new columns will not become part of the view.
      In all cases, the view definition (view structure) is frozen
      at CREATE time, so changes to the underlying tables do not
      affect the view structure.
      a1666e06
  7. 29 Nov, 2007 1 commit
    • davi@mysql.com/endora.local's avatar
      Bug#23713 LOCK TABLES + CREATE TRIGGER + FLUSH TABLES WITH READ LOCK = deadlock · d179bb64
      davi@mysql.com/endora.local authored
      This bug is actually two bugs in one, one of which is CREATE TRIGGER under
      LOCK TABLES and the other is CREATE TRIGGER under LOCK TABLES simultaneous
      to a FLUSH TABLES WITH READ LOCK (global read lock). Both situations could
      lead to a server crash or deadlock.
      
      The first problem arises from the fact that when under LOCK TABLES, if the
      table is in the set of locked tables, the table is already open and it doesn't
      need to be reopened (not a placeholder). Also in this case, if the table is
      not write locked, a exclusive lock can't be acquired because of a possible
      deadlock with another thread also holding a (read) lock on the table. The
      second issue arises from the fact that one should never wait for a global
      read lock if it's holding any locked tables, because the global read lock
      is waiting for these tables and this leads to a circular wait deadlock.
      
      The solution for the first case is to check if the table is write locked
      and upgraded the write lock to a exclusive lock and fail otherwise for non
      write locked tables. Grabbin the exclusive lock in this case also means
      to ensure that the table is opened only by the calling thread. The second
      issue is partly fixed by not waiting for the global read lock if the thread
      is holding any locked tables.
      
      The second issue is only partly addressed in this patch because it turned
      out to be much wider and also affects other DDL statements. Reported as
      Bug#32395
      d179bb64
  8. 28 Nov, 2007 13 commits
  9. 27 Nov, 2007 9 commits