1. 20 Nov, 2009 8 commits
    • Konstantin Osipov's avatar
      Backport the test case for Bug#31881 "A statement is not aborted immediately if an error · 9a104341
      Konstantin Osipov authored
       inside a stored routine" from 6.0-codebase.
      9a104341
    • Konstantin Osipov's avatar
      Backport of: · ef4bd979
      Konstantin Osipov authored
      ------------------------------------------------------------
      revno: 2597.42.4
      committer: davi@mysql.com/endora.local
      timestamp: Tue 2008-04-15 17:29:42 -0300
      message:
      Bug#36004 mysql_stmt_prepare resets the list of warnings
      
      Although the manual says that "the list of messages is reset
      for each new statement that uses a table", the list of messages
      is being unconditionally reset for prepare commands.
      
      The solution is to enforce that the prepare command will only
      reset the message list if the statement being prepared uses
      a table or a warning is pushed.
      ef4bd979
    • Konstantin Osipov's avatar
    • Konstantin Osipov's avatar
      Backport of: · 5a78d2a7
      Konstantin Osipov authored
      ------------------------------------------------------------
      revno: 2572.23.1
      committer: davi@mysql.com/endora.local
      timestamp: Wed 2008-03-19 09:03:08 -0300
      message:
      Bug#17954 Threads_connected > Threads_created
      
      The problem is that insert delayed threads are counted as connected
      but not as created, leading to a Threads_connected value greater then
      the Threads_created value.
      
      The solution is to enforce the documented behavior that the
      Threads_connected value shall be the number of currently
      open connections and that Threads_created shall be the
      number of threads created to handle connections.
      5a78d2a7
    • Konstantin Osipov's avatar
      Backport of: · 36ab5d79
      Konstantin Osipov authored
      ------------------------------------------------------------
      revno: 2476.1116.1
      committer: davi@mysql.com/endora.local
      timestamp: Fri 2007-12-14 10:10:19 -0200
      message:
      DROP TABLE under LOCK TABLES simultaneous to a FLUSH TABLES
      WITH READ LOCK (global read lock) can lead to a deadlock.
      
      The solution is to not wait for the global read lock if the
      thread is holding any locked tables.
      
      Related to bugs 23713 and 32395. This issues is being fixed
      only on 6.0 because it depends on the fix for bug 25858 --
      which was fixed only on 6.0.
      36ab5d79
    • Konstantin Osipov's avatar
      Backport of: · 1ee8a588
      Konstantin Osipov authored
      ------------------------------------------------------------
      revno: 2476.784.3
      committer: davi@moksha.local
      timestamp: Tue 2007-10-02 21:27:31 -0300
      message:
      Bug#25858 Some DROP TABLE under LOCK TABLES can cause deadlocks
              
      When a client (connection) holds a lock on a table and attempts to
      drop (obtain a exclusive lock) on a second table that is already
      held by a second client and the second client then attempts to
      drop the table that is held by the first client, leads to a
      circular wait deadlock. This scenario is very similar to trying to
      drop (or rename) a table while holding read locks and are
      correctly forbidden.
              
      The solution is to allow a drop table operation to continue only
      if the table being dropped is write (exclusively) locked, or if
      the table is temporary, or if the client is not holding any
      locks. Using this scheme prevents the creation of a circular
      chain in which each client is waiting for one table that the
      next client in the chain is holding.
                  
      This is incompatible change, as can be seen by number of tests
      cases that needed to be fixed, but is consistent with respect to
      behavior of the different scenarios in which the circular wait
      might happen.
      1ee8a588
    • Konstantin Osipov's avatar
      Backport of: · 948ee7e5
      Konstantin Osipov authored
      revno: 2476.784.2
      committer: davi@moksha.local
      timestamp: Thu 2007-09-27 16:56:27 -0300 
      message:
      Bug#28870 check that table locks are released/reset
          
      The problem is that some mysql_lock_tables error paths are not
      resetting the tables lock type back to TL_UNLOCK. If the lock
      types are not reset properly, a table might be returned to the
      table cache with wrong lock_type.
            
      The proposed fix is to ensure that the tables lock type is always
      properly reset when mysql_lock_tables fails. This is a
      incompatible change with respect to the process state information.
      948ee7e5
    • Magne Mahre's avatar
      Enable test cases for Bug#6063 and Bug#7088. · 2564b504
      Magne Mahre authored
      2564b504
  2. 19 Nov, 2009 1 commit
  3. 13 Nov, 2009 1 commit
  4. 12 Nov, 2009 6 commits
  5. 11 Nov, 2009 10 commits
  6. 10 Nov, 2009 14 commits
    • Alexey Botchkov's avatar
      Bug #47139 Test "merge" crashes in "embedded" run · 64341975
      Alexey Botchkov authored
        In fact this crashes in normal (not embedded) run also.
        The problem is in the memory mapping. Handling the ha_myisammrg::extra(MMAP)
        the MERGE engine tries to mmap all the tables it unites.
        Though some can be empty and then in the mi_dynmap_file()
        we call the my_mmap(0). Normally this call returns MAP_FAILED,
        but not on FreeBSD. There it returns like a 'normal' value,
        and after the consequitive munmap systems gets unstable and
        crashes on some system call later.
      
      per-file comments:
        storage/myisam/mi_dynrec.c
      Bug #47139      Test "merge" crashes in "embedded" run
          don't try to mmap zero-length area, just return at once.
      64341975
    • Alexey Botchkov's avatar
      Bug#42520 killing load .. infile Assertion failed: ! is_set(), file .\sql_error.cc, line 8 · 6d9aa9ea
      Alexey Botchkov authored
         The additional patch. That 'loadxml.test' failure was actually about our testing system,
         not the code.
         Firstly we need a new mysqltest command, wich i called 'send_eval'. So the expression
         can be evaluated, then started in a parallel thread. We only have separane 'send' and
         'eval' commands at the moment.
         Then we need to add the waiting code after the 'KILL' to our test, so the thread will be killed
         before the test goes further. The present 'reap' command doesn't handle the killed threads
         well.
            
      per-file comments:
        client/mysqltest.cc
      Bug#42520      killing load .. infile Assertion failed: ! is_set(), file .\sql_error.cc, line 8
          The 'send_eval' command implemented.
      
        mysql-test/r/loadxml.result
      Bug#42520      killing load .. infile Assertion failed: ! is_set(), file .\sql_error.cc, line 8
         test result updated.
      
        mysql-test/t/loadxml.test
      Bug#42520      killing load .. infile Assertion failed: ! is_set(), file .\sql_error.cc, line 8
         test case added.
      6d9aa9ea
    • Davi Arnaut's avatar
      Backport of Bug#45767 to mysql-next-mr · ed800b5d
      Davi Arnaut authored
      ------------------------------------------------------------
      revno: 3405
      revision-id: davi.arnaut@sun.com-20090626124624-m4wolyo5193j4cu7
      parent: luis.soares@sun.com-20090626113019-1j4mn1jos480u9f3
      committer: Davi Arnaut <Davi.Arnaut@Sun.COM>
      branch nick: mysql-pe
      timestamp: Fri 2009-06-26 09:46:24 -0300
      message:
        Bug#45767: deprecate/remove Field::pack_key, Field::unpack_key, Field::pack_cmp
        
        Remove unused and dead code.
        
        Parts of the patch contributed by Zardosht Kasheff
      ed800b5d
    • Davi Arnaut's avatar
      Backport of Bug#27249 to mysql-next-mr · add210fe
      Davi Arnaut authored
      ------------------------------------------------------------
      revno: 2476.784.4
      revision-id: sp1r-davi@moksha.local-20071008114751-46069
      parent: sp1r-davi@moksha.local-20071003002731-48537
      committer: davi@moksha.local
      timestamp: Mon 2007-10-08 08:47:51 -0300
      message:
        Bug#27249 table_wild with alias: select t1.* as something
      
        Aliases to table wildcards are silently ignored, but they should
        not be allowed as it is non-standard and currently useless. There
        is not point in having a alias to a wildcard of column names.
      
        The solution is to rewrite the select_item rule so that aliases
        for table wildcards are not accepted.
      
        Contribution by Martin Friebe
      add210fe
    • Davi Arnaut's avatar
      Backport of Bug#15192 to mysql-next-mr · a7bbc779
      Davi Arnaut authored
      ------------------------------------------------------------
      revno: 2597.4.17
      revision-id: sp1r-davi@mysql.com/endora.local-20080328174753-24337
      parent: sp1r-anozdrin/alik@quad.opbmk-20080328140038-16479
      committer: davi@mysql.com/endora.local
      timestamp: Fri 2008-03-28 14:47:53 -0300
      message:
        Bug#15192 "fatal errors" are caught by handlers in stored procedures
      
        The problem is that fatal errors (e.g.: out of memory) were being
        caught by stored procedure exception handlers which could cause
        the execution to not be stopped due to a continue handler.
      
        The solution is to not call any exception handler if the error is
        fatal and send the fatal error to the client.
      a7bbc779
    • Davi Arnaut's avatar
      Backport of Bug#41860 to mysql-next-mr · 5783428f
      Davi Arnaut authored
      ------------------------------------------------------------
      revno: 3317
      revision-id: davi.arnaut@sun.com-20090522170916-fzc5ca3tjs9roy1t
      parent: patrick.crews@sun.com-20090522152933-ole8s3suy4zqyvku
      committer: Davi Arnaut <Davi.Arnaut@Sun.COM>
      branch nick: 41860-6.0
      timestamp: Fri 2009-05-22 14:09:16 -0300
      message:
        Bug#41860: Without Windows named pipe
      
        The problem was that the patch for Bug#10374 broke named pipe
        and shared memory transports on Windows due to a failure to
        implement a dummy poll method for transports other than BSD
        sockets. Another problem was that mysqltest lacked support
        for named pipe and shared memory connections, which lead to
        misleading test cases that were supposed run common queries
        over both transports.
      
        The solution is to properly implement, at the VIO layer, the
        poll and is_connected methods. The is_connected method is
        implemented for every suppported transport and the poll one
        only where it makes sense. Furthermore, support for named pipe
        and shared memory connections is added to mysqltest as to
        enable testing of both transports using the test suite.
      5783428f
    • Davi Arnaut's avatar
      Backport of Bug#10374 to mysql-next-mr · 58706b3f
      Davi Arnaut authored
      ------------------------------------------------------------
      revno: 2597.37.3
      revision-id: sp1r-davi@mysql.com/endora.local-20080328123626-16430
      parent: sp1r-anozdrin/alik@quad.opbmk-20080327125300-11290
      committer: davi@mysql.com/endora.local
      timestamp: Fri 2008-03-28 09:36:26 -0300
      message:
        Bug#10374 GET_LOCK does not let connection to close on the server side if it's aborted
      
        The problem is that the server doesn't detect aborted connections which
        are waiting on a lock or sleeping (user sleep), wasting system resources
        for a connection that is already dead.
      
        The solution is to peek at the connection every five seconds to verify if
        the connection is not aborted. A aborted connection is detect by polling
        the connection socket for available data to be read or end of file and in
        case of eof, the wait is aborted and the connection killed.
      58706b3f
    • Davi Arnaut's avatar
      Backport of Bug#27525 to mysql-next-mr · 40c127eb
      Davi Arnaut authored
      ------------------------------------------------------------
      revno: 2572.2.1
      revision-id: sp1r-davi@mysql.com/endora.local-20080227225948-16317
      parent: sp1r-anozdrin/alik@quad.-20080226165712-10409
      committer: davi@mysql.com/endora.local
      timestamp: Wed 2008-02-27 19:59:48 -0300
      message:
        Bug#27525 table not found when using multi-table-deletes with aliases over several databas
        Bug#30234 Unexpected behavior using DELETE with AS and USING
      
        The multi-delete statement has a documented limitation that
        cross-database multiple-table deletes using aliases are not
        supported because it fails to find the tables by alias if it
        belongs to a different database. The problem is that when
        building the list of tables to delete from, if a database
        name is not specified (maybe an alias) it defaults to the
        name of the current selected database, making impossible to
        to properly resolve tables by alias later. Another problem
        is a inconsistency of the multiple table delete syntax that
        permits ambiguities in a delete statement (aliases that refer
        to multiple different tables or vice-versa).
      
        The first step for a solution and proper implementation of
        the cross-databse multiple table delete is to get rid of any
        ambiguities in a multiple table statement. Currently, the parser
        is accepting multiple table delete statements that have no obvious
        meaning, such as:
      
        DELETE a1 FROM db1.t1 AS a1, db2.t2 AS a1;
        DELETE a1 AS a1 FROM db1.t1 AS a1, db2.t2 AS a1;
      
        The solution is to resolve the left part of a delete statement
        using the right part, if the a table on right has an alias,
        it must be referenced in the left using the given alias. Also,
        each table on the left side must match unambiguously only one
        table in the right side.
      40c127eb
    • Davi Arnaut's avatar
      Backport of Bug#37843 to mysql-next-mr · b53bb567
      Davi Arnaut authored
      b53bb567
    • Davi Arnaut's avatar
      Backport of Bug#36785 to mysql-next-mr · 7d0ae745
      Davi Arnaut authored
      ------------------------------------------------------------
      revno: 2630.2.13
      revision-id: davi@mysql.com-20080612190452-cx6h7rm557bcq7sa
      parent: davi@mysql.com-20080611124915-csejwrxfdga9upho
      committer: Davi Arnaut <davi@mysql.com>
      branch nick: 36785-6.0
      timestamp: Thu 2008-06-12 16:04:52 -0300
      message:
        Bug#36785: Wrong error message when group_concat() exceeds max length
      
        The problem is that when ER_CUT_VALUE_GROUP_CONCAT is elevated
        to a error, the message does not get updated with the number of
        cut lines when group_concat() exceeds max length.
      
        The solution is to modify the warning message to be more meaningful
        by giving the number of the line that was cut and to issue the warning
        for each line that is cut. This approach is inline with how other
        per-row truncated data warnings are issued avoids violating the warning
        internal interface.
      7d0ae745
    • Davi Arnaut's avatar
      Backport of Bug#32140 to mysql-next-mr · 3e82db82
      Davi Arnaut authored
      ------------------------------------------------------------
      revno: 2618
      revision-id: sp1r-davi@mysql.com/endora.local-20080418131946-26951
      parent: sp1r-davi@mysql.com/endora.local-20080417190810-26185
      committer: davi@mysql.com/endora.local
      timestamp: Fri 2008-04-18 10:19:46 -0300
      message:
        Bug#32140: wrong error code caught when an SF() call is interruped with KILL query
      
        The problem is that killing a query which calls a stored function
        could return a wrong error (table corrupt) instead of the query
        interrupted error message.
      
        The solution is to not set the table corrupt error if the query
        is killed, the query interrupted error message will be set  later
        when the query is finished.
      3e82db82
    • Davi Arnaut's avatar
      Backport of Bug#36649 to mysql-next-mr · 20189faa
      Davi Arnaut authored
      ------------------------------------------------------------
      revno: 2630.39.3
      revision-id: davi.arnaut@sun.com-20081210215359-i876m4zgc2d6rzs3
      parent: kostja@sun.com-20081208222938-9es7wl61moli71ht
      committer: Davi Arnaut <Davi.Arnaut@Sun.COM>
      branch nick: 36649-6.0
      timestamp: Wed 2008-12-10 19:53:59 -0200
      message:
        Bug#36649: Condition area is not properly cleaned up after stored routine invocation
      
        The problem is that the diagnostics area of a trigger is not
        isolated from the area of the statement that caused the trigger
        invocation. In MySQL terms, it means that warnings generated
        during the execution of the trigger are not removed from the
        "warning area" at the end of the execution.
      
        Before this fix, the rules for MySQL message list life cycle (see
        manual entry for SHOW WARNINGS) did not apply to statements
        inside stored programs:
      
          - The manual says that the list of messages is cleared by a
            statement that uses a table (any table). However, such
            statement, if run inside a stored program did not clear the
            message list.
          - The manual says that the list is cleared by a statement that
            generates a new error or a warning, but this was not the case
            with stored program statements either and is changed to be the
            case as well.
      
        In other words, after this fix, a statement has the same effect
        on the message list regardless of whether it's executed inside a
        stored program/sub-statement or not.
      
        This introduces an incompatible change:
      
          - before this fix, a, e.g. statement inside a trigger could
            never clear the global warning list
          - after this fix, a trigger that generates a warning or uses a
            table, clears the global warning list
          - however, when we leave a trigger or a function, the caller's
            warning information is restored (see more on this below).
      
        This change is not backward compatible as it is intended to make
        MySQL behavior similar to the SQL standard behavior:
      
        A stored function or trigger will get its own "warning area" (or,
        in standard terminology, diagnostics area).  At the beginning of
        the stored function or trigger, all messages from the caller area
        will be copied to the area of the trigger.  During execution, the
        message list will be cleared according to the MySQL rules
        described on the manual (SHOW WARNINGS entry).  At the end of the
        function/trigger, the "warning area" will be destroyed along with
        all warnings it contains, except that if the last statement of
        the function/trigger generated messages, these are copied into
        the "warning area" of the caller.
      
        Consequently, statements that use a table or generate a warning
        *will* clear warnings inside the trigger, but that will have no
        effect to the warning list of the calling (outer) statement.
      20189faa
    • Kristofer Pettersson's avatar
      automerge · 05764e29
      Kristofer Pettersson authored
      05764e29
    • Kristofer Pettersson's avatar
      Bug#27145 EXTRA_ACL troubles · 08aecd54
      Kristofer Pettersson authored
      Correction of backport patch:
      * Fixed signature of check_access_table() for embedded build
      * Fixed typo for last argument in a check_access() call from UINT_MAX to 0.
      08aecd54