1. 28 May, 2007 3 commits
    • unknown's avatar
      Bug#24988 FLUSH PRIVILEGES causes brief unavailability · 416122b2
      unknown authored
      - A race condition caused brief unavailablility when trying to acccess
        a table. 
      - The variable 'grant_option' was removed to resolve the race condition and
        to simplify the design pattern. This flag was originally intended to optimize
        grant checks.
      
      
      sql/mysql_priv.h:
        - removed 'grant_option' flag.
      sql/sql_acl.cc:
        - removed 'grant_option' flag.
      sql/sql_db.cc:
        - removed 'grant_option' flag.
      sql/sql_insert.cc:
        - removed 'grant_option' flag.
      sql/sql_parse.cc:
        - removed 'grant_option' flag.
        - removed unnecessary variables found_access, found
      sql/sql_show.cc:
        - removed 'grant_option' flag.
      sql/sql_update.cc:
        - removed 'grant_option' flag.
      sql/sql_view.cc:
        - removed 'grant_option' flag.
      416122b2
    • unknown's avatar
      Merge adventure.(none):/home/thek/Development/cpp/bug24988/my50-bug24988 · 2c06c07a
      unknown authored
      into  adventure.(none):/home/thek/Development/cpp/bug24988/my51-bug24988
      
      
      sql/mysqld.cc:
        Auto merged
      sql/sql_acl.cc:
        Auto merged
      2c06c07a
    • unknown's avatar
      Bug#24988 FLUSH PRIVILEGES causes brief unavailability · 96d16d96
      unknown authored
      - A race condition caused brief unavailablility when trying to acccess
        a table.
      - The unprotected variable 'grant_option' wasn't intended to alternate
        during normal execution. Variable initialization moved to grant_init
        a lines responsible for the alternation are removed. 
      
      
      sql/mysqld.cc:
        - Added documentation to describe grant_option flag.
      sql/sql_acl.cc:
        - This patch removes lines which causes grant_option to alternate and moves
          variable initialization to the grant_init()-function.
      96d16d96
  2. 24 May, 2007 4 commits
  3. 23 May, 2007 7 commits
    • unknown's avatar
      Merge mockturtle.local:/home/dlenev/src/mysql-5.0-like · b24c1b04
      unknown authored
      into  mockturtle.local:/home/dlenev/src/mysql-5.1-like-2
      
      
      sql/handler.h:
        Auto merged
      sql/mysql_priv.h:
        5.1 version of mysql_priv.h already contains all necessary changes.
      sql/sql_parse.cc:
        5.1 version of sql_parse.cc already contains all necessary changes.
      sql/sql_table.cc:
        5.1 version of sql_table.cc already contains all necessary changes.
      sql/sql_yacc.yy:
        SCCS merged
      mysql-test/r/grant2.result:
        Manual merge.
      mysql-test/t/grant2.test:
        Manual merge.
      b24c1b04
    • unknown's avatar
      Merge bk-internal.mysql.com:/home/bk/mysql-5.1-runtime · 4b9b1eda
      unknown authored
      into  mockturtle.local:/home/dlenev/src/mysql-5.1-like-2
      
      
      sql/sql_parse.cc:
        Auto merged
      4b9b1eda
    • unknown's avatar
      5.1 version of fix for: · 206a6bb1
      unknown authored
        Bug #23667 "CREATE TABLE LIKE is not isolated from alteration
                    by other connections"
        Bug #18950 "CREATE TABLE LIKE does not obtain LOCK_open"
      As well as:
        Bug #25578 "CREATE TABLE LIKE does not require any privileges
                    on source table".
      
      The first and the second bugs resulted in various errors and wrong
      binary log order when one tried to execute concurrently CREATE TABLE LIKE
      statement and DDL statements on source table or DML/DDL statements on its
      target table.
      
      The problem was caused by incomplete protection/table-locking against
      concurrent statements implemented in mysql_create_like_table() routine.
      We solve it by simply implementing such protection in proper way.
      Most of actual work for 5.1 was already done by fix for bug 20662 and
      preliminary patch changing locking in ALTER TABLE.
      
      The third bug allowed user who didn't have any privileges on table create
      its copy and therefore circumvent privilege check for SHOW CREATE TABLE.
      
      This patch solves this problem by adding privilege check, which was missing.
      
      Finally it also removes some duplicated code from mysql_create_like_table()
      and thus fixes bug #26869 "TABLE_LIST::table_name_length inconsistent with
      TABLE_LIST::table_name".
      
      
      mysql-test/r/create-big.result:
        Added test coverage for concurrency-related issues with CREATE TABLE LIKE.
      mysql-test/r/create.result:
        Adjusted error-code in the test case after refactoring code that
        implements CREATE TABLE ... LIKE.
      mysql-test/r/grant2.result:
        Added test for bug#25578 "CREATE TABLE LIKE does not require any privileges
        on source table".
      mysql-test/t/create-big.test:
        Added test coverage for concurrency-related issues with CREATE TABLE LIKE.
      mysql-test/t/create.test:
        Adjusted error-code in the test case after refactoring code that
        implements CREATE TABLE ... LIKE.
      mysql-test/t/disabled.def:
        Recent code changes ensured that CREATE TABLE LIKE statement is properly
        isolated against other statements, so synchronization.test should no
        longer fail (see fix for bug 20662 and preliminary patch for bug 23667
        changing ALTER TABLE locking).
      mysql-test/t/grant2.test:
        Added test for bug#25578 "CREATE TABLE LIKE does not require any privileges
        on source table".
      sql/handler.h:
        Introduced new flag for HA_CREATE_INFO::options in order to be able to
        distinguish CREATE TABLE ... LIKE from other types of CREATE TABLE.
      sql/mysql_priv.h:
        mysql_create_like_table() now takes source table name not as a
        Table_ident object but as regular table list element.
      sql/sql_lex.h:
        Removed LEX::like_name member. Now we use special flag in
        LEX::create_info::options for distinguishing CREATE TABLE ... LIKE
        from other types of CREATE TABLE and store name of source table as
        regular element in statement's table list.
      sql/sql_parse.cc:
        CREATE TABLE ... LIKE implementation now uses statement's table list
        for storing information about the source table. We also use flag
        in LEX::create_info.options for distinguishing it from other types
        of CREATE TABLE.
        Finally CREATE TABLE ... LIKE now requires the same privileges on
        the source tables as SHOW CREATE TABLE. Moved this privilege check
        to check_show_create_table_access() function.
      sql/sql_partition.cc:
        Now we use special flag in LEX::create_info::options for distinguishing
        CREATE TABLE ... LIKE from other types of CREATE TABLE and store name
        of source table as regular element in statement's table list.
      sql/sql_table.cc:
        mysql_create_like_table():  
         - Commented and cleaned-up a bit code which is responsible for achieving
           isolation from concurrent statements. Most of actual work was done by
           fix for bug 20662 and preliminary patch changing locking locking in
           ALTER TABLE, so here we do minor things like relaxing locking on
           source table (we don't need lock on it, to have it open is enough) and
           adjusting code to make it more friendly against code implementing I_S.
         - Get rid of duplicated code related to source database/table name
           handling. All these operations are already done in
           st_select_lex::add_table_to_list(), so we achieve the same effect
           by including source table into the statement's table list.
      sql/sql_yacc.yy:
        Now we use special flag in LEX::create_info::options for distinguishing
        CREATE TABLE ... LIKE from other types of CREATE TABLE and store name
        of source table as regular element in statement's table list.
      206a6bb1
    • unknown's avatar
      5.0 version of fix for: · f9d7642e
      unknown authored
       Bug #23667 "CREATE TABLE LIKE is not isolated from alteration
                   by other connections"
       Bug #18950 "CREATE TABLE LIKE does not obtain LOCK_open"
      As well as:
       Bug #25578 "CREATE TABLE LIKE does not require any privileges
                   on source table".
      
      The first and the second bugs resulted in various errors and wrong
      binary log order when one tried to execute concurrently CREATE TABLE LIKE
      statement and DDL statements on source table or DML/DDL statements on its
      target table.
      
      The problem was caused by incomplete protection/table-locking against
      concurrent statements implemented in mysql_create_like_table() routine.
      We solve it by simply implementing such protection in proper way (see
      comment for sql_table.cc for details).
      
      The third bug allowed user who didn't have any privileges on table create
      its copy and therefore circumvent privilege check for SHOW CREATE TABLE.
      
      This patch solves this problem by adding privilege check, which was missing.
      
      Finally it also removes some duplicated code from mysql_create_like_table().
      
      Note that, altough tests covering concurrency-related aspects of CREATE TABLE
      LIKE behaviour will only be introduced in 5.1, they were run manually for
      this patch as well.
      
      
      mysql-test/r/grant2.result:
        Added test for bug#25578 "CREATE TABLE LIKE does not require any privileges
        on source table".
      mysql-test/t/grant2.test:
        Added test for bug#25578 "CREATE TABLE LIKE does not require any privileges
        on source table".
      sql/handler.h:
        Introduced new flag for HA_CREATE_INFO::options in order to be able to
        distinguish CREATE TABLE ... LIKE from other types of CREATE TABLE.
      sql/mysql_priv.h:
        mysql_create_like_table() now takes source table name not as a
        Table_ident object but as regular table list element.
      sql/sql_parse.cc:
        CREATE TABLE ... LIKE implementation now uses statement's table list
        for storing information about the source table. We also use flag
        in LEX::create_info.options for distinguishing it from other types
        of CREATE TABLE.
        Finally CREATE TABLE ... LIKE now requires the same privileges on
        the source tables as SHOW CREATE TABLE. Moved this privilege check
        to check_show_create_table_access() function.
      sql/sql_table.cc:
        mysql_create_like_table():
         - Provided proper protection from concurrent statements.
           This is achieved by keeping name-lock on the source table and holding
           LOCK_open mutex during whole operation. This gives protection against
           concurrent DDL on source table. Also holding this mutex makes copying
           of .frm file, call to ha_create_table() and binlogging atomic against
           concurrent DML and DDL operations on target table.
         - Get rid of duplicated code related to source database/table name
           handling. All these operations are already done in
           st_select_lex::add_table_to_list(), so we achieve the same effect
           by including source table into the statement's table list.
      sql/sql_yacc.yy:
        Now we use special flag in LEX::create_info::options for distinguishing
        CREATE TABLE ... LIKE from other types of CREATE TABLE and store name
        of source table as regular element in statement's table list.
      f9d7642e
    • unknown's avatar
      - Corrected type misstake in debug statement. · 7f35d66d
      unknown authored
      7f35d66d
    • unknown's avatar
      Merge adventure.(none):/home/thek/Development/cpp/bug21074/my51-bug21074 · 3807b25e
      unknown authored
      into  adventure.(none):/home/thek/Development/cpp/mysql-5.1-runtime
      
      
      sql/set_var.cc:
        Auto merged
      sql/sql_cache.cc:
        Auto merged
      3807b25e
    • unknown's avatar
      - This patch addesses the performance issues with invalidating the entire · 54807084
      unknown authored
        cache by changing the behavior of the query cache resize-method.
      - set query_cache_size=<new_size>; is significantly faster than RESET QUERY
        CACHE as it simply destroys and recreates the query cache, whereas
        RESET QUERY CACHE keeps its internal structure aligned with server 
        load profile.
      
      
      sql/set_var.cc:
        Refactored behavior of function. Instead of setting the global variable
        from within the class method scope we return the new cache size as a 
        result of the method call.
      sql/sql_cache.cc:
        - Changed behavior of resize-method. Now, the cache will be cleared as one
          single block of data instead of an iteration over all cached statements.
      54807084
  4. 22 May, 2007 4 commits
    • unknown's avatar
      build break cleanup · e5fe0261
      unknown authored
      
      include/config-win.h:
        cleanup, windows build break
      include/my_pthread.h:
        cleanup, windows build break
      sql/event_queue.cc:
        warnings cleanup, unititialized waiting_on_cond
      tests/mysql_client_test.c:
        warnings cleanup
      e5fe0261
    • unknown's avatar
      Merge malff@bk-internal.mysql.com:/home/bk/mysql-5.1-runtime · 2e6e572f
      unknown authored
      into  weblab.(none):/home/marcsql/TREE/mysql-5.1-21554-merge
      
      
      2e6e572f
    • unknown's avatar
      Bug#21554 (sp_cache.cc: violates C++ aliasing rules) · bb64e39e
      unknown authored
      The problem reported is a compile bug,
      reported by the development GCC team with GCC 4.2.
      
      The original issue can no longer be reproduced in MySQL 5.1,
      since the configure script no longer define HAVE_ATOMIC_ADD,
      which caused the Linux atomic functions to be used (and cause a problem
      with an invalid cast).
      
      This patch implements some code cleanup for 5.1 only, which was identified
      during the investigation of this issue.
      
      With this patch, statistics maintained in THD::status_var are by definition
      owned by the running thread, and do not need to be protected against race
      conditions. These statistics are maintained by the status_var_* helpers,
      which do not require any lock.
      
      
      include/my_global.h:
        General cleanup of thread_safe_increment / statistic_increment
      include/my_pthread.h:
        General cleanup of thread_safe_increment / statistic_increment
      sql/filesort.cc:
        General cleanup of thread_safe_increment / statistic_increment
      sql/handler.cc:
        General cleanup of thread_safe_increment / statistic_increment
      sql/sql_insert.cc:
        General cleanup of thread_safe_increment / statistic_increment
      sql/sql_parse.cc:
        General cleanup of thread_safe_increment / statistic_increment
      sql/sql_prepare.cc:
        General cleanup of thread_safe_increment / statistic_increment
      sql/sql_select.cc:
        General cleanup of thread_safe_increment / statistic_increment
      bb64e39e
    • unknown's avatar
      Test case for bug#28075 · 79a6e53e
      unknown authored
      
      tests/mysql_client_test.c:
        Add a test case for bug#28075 - just send COM_DEBUG and check whether
        the server is still alive.
      79a6e53e
  5. 21 May, 2007 1 commit
    • unknown's avatar
      Fix for bug#28075 COM_DEBUG crashes mysqld · 3da4eef7
      unknown authored
      Uninitialized in the constructor member variables were
      pointing to nirvana and causing a crash when debug information
      of the Event Scheduler was dumped in result to COM_DEBUG
      packet sent to the server.
      
      
      sql/event_queue.cc:
        Initialize member variables or they will point to
        nirvana and could possible cause a crash during
        dumping of debug information.
      sql/event_queue.h:
        remove unneeded line
      sql/event_scheduler.cc:
        Initialize member variables or they will point to
        nirvana and could possible cause a crash during
        dumping of debug information.
      sql/event_scheduler.h:
        remove unneeded state
      3da4eef7
  6. 19 May, 2007 2 commits
    • unknown's avatar
      Merge bk-internal.mysql.com:/home/bk/mysql-5.1-runtime · 3d01594f
      unknown authored
      into  mockturtle.local:/home/dlenev/src/mysql-5.1-alter
      
      
      sql/sql_base.cc:
        Auto merged
      3d01594f
    • unknown's avatar
      Patch changing how ALTER TABLE implementation handles table locking · 1a60685c
      unknown authored
      and invalidation in the most general case (non-temporary table and
      not simple RENAME or ENABLE/DISABLE KEYS or partitioning command).
      
      See comment for sql/sql_table.cc for more information.
      
      These changes are prerequisite for 5.1 version of fix for bug #23667
      "CREATE TABLE LIKE is not isolated from alteration by other connections"
      
      
      mysql-test/include/mix1.inc:
        Extended coverage for behavior of ALTER TABLE statement under LOCK TABLES,
        which should be consistent across all platforms and for all engines.
      mysql-test/r/alter_table-big.result:
        Changed test for bug #25044 to use @@debug and injected sleeps
        infrastructure. Extended test coverage for ALTER TABLE's behavior
        under concurrency.
      mysql-test/r/alter_table.result:
        Extended coverage for behavior of ALTER TABLE statement under LOCK TABLES,
        which should be consistent across all platforms and for all engines.
      mysql-test/r/innodb_mysql.result:
        Extended coverage for behavior of ALTER TABLE statement under LOCK TABLES,
        which should be consistent across all platforms and for all engines.
      mysql-test/t/alter_table-big.test:
        Changed test for bug #25044 to use @@debug and injected sleeps
        infrastructure. Extended test coverage for ALTER TABLE's behavior
        under concurrency.
      mysql-test/t/alter_table.test:
        Extended coverage for behavior of ALTER TABLE statement under LOCK TABLES,
        which should be consistent across all platforms and for all engines.
      sql/mysql_priv.h:
        Made functions reopen_table() and close_handle_and_leave_table_as_lock()
        available outside of sql_base.cc file.
        Changed close_data_tables() in such way that after closing handler
        for the table it leaves TABLE object for it in table cache not as
        placeholder for ordinary name-lock but as placeholder for an exclusive
        name-lock. Renamed this routine to close_data_files_and_morph_locks().
      sql/sql_base.cc:
        Made functions reopen_table() and close_handle_and_leave_table_as_lock()
        available outside of sql_base.cc file.
        Changed close_data_tables() in such way that after closing handler
        for the table it leaves TABLE object for it in table cache not as
        placeholder for ordinary name-lock but as placeholder for an exclusive
        name-lock. Renamed this routine to close_data_files_and_morph_locks().
        Also adjusted it so it can work properly not only in LOCK TABLES mode.
      sql/sql_table.cc:
        Changed the way in which ALTER TABLE implementation handles table
        locking and invalidation in the most general case (non-temporary table
        and not simple RENAME or ENABLE/DISABLE KEYS or partitioning command)
        
        Now after preparing new version of the table we:
        1) Wait until all other threads close old version of table.
        2) Close instances of table open by this thread and replace them
           with exclusive name-locks.
        3) Rename the old table to a temp name, rename the new one to the
           old name.
        4) If we are under LOCK TABLES and don't do ALTER TABLE ... RENAME
           we reopen new version of table.
        5) Write statement to the binary log.
        6) If we are under LOCK TABLES and do ALTER TABLE ... RENAME we
           remove name-locks from list of open tables and table cache.
        7) If we are not not under LOCK TABLES we rely on close_thread_tables()
           call to remove name-locks from table cache and list of open table. 
        
        Such approach:
        a) Eliminates possibility for concurrent statement to sneak in and get
           access to the new version of the table before ALTER TABLE gets logged
           into binary log.
        b) Ensures that ALTER TABLE behaves under LOCK TABLES in the same way
           on all platforms and for all engines (in 5.0 this was not true) 
        c) Preserves nice invariant that if table is open in some connection
           there is a guarantee that .FRM file for this table exists and is
           properly named.
      1a60685c
  7. 18 May, 2007 4 commits
    • unknown's avatar
      Merge adventure.(none):/home/thek/Development/cpp/bug26277/my51-bug26277 · ad4da535
      unknown authored
      into  adventure.(none):/home/thek/Development/cpp/mysql-5.1-runtime
      
      
      mysql-test/t/sp-vars.test:
        Auto merged
      sql/item_func.cc:
        Auto merged
      sql/item_func.h:
        Auto merged
      mysql-test/r/sp-vars.result:
        manual merge
      ad4da535
    • unknown's avatar
      Bug#26277 User variable returns one type in SELECT @v and other for CREATE as SELECT @v · 755ae21b
      unknown authored
      - Adding variable m_cached_result_type to keep the variable type consistent
        during the execution of a statement.
      - Before each result set is returned to the client the description of each
        column is sent as meta data.
        Previously the result type for a column could change if the hash variable
        entry changed between statements. This caused the result set of the query
        to alternate column types in certain cases which is not supported by MySQL
        client-server protocol. Example:
        Previously this sequence:
          SET @A:=1;
          SELECT @A:="text", @A;
        would return "text", "text";
       
        After the change the SELECT returns "text", 0
        The reson for this is that previously the result set from 'SELECT @A;'
        would always be of the type STRING, whereas now the type of the variable
        is taken from the last SET statement. However, 'SELECT @A:="text"' will
        return type of STRING since the right side of the assignment is used.
      
      
      mysql-test/r/ps_2myisam.result:
        Changed test result because SQL type of a user variable now
        more accurately represents its Item type: since Item type of a variable
        can be either STRING, INT, DECIMAL or DOUBLE, SQL type of the
        result set metadata now can be either MYSQL_TYPE_VARCHAR,
        MYSQL_TYPE_LONGLONG, MYSQL_TYPE_NEWDECIMAL or MYSQL_TYPE_DOUBLE.
        
        Previously it was always MYSQL_TYPE_VARCHAR.
        
        In particular, integer variables now have changed from
        MYSQL_TYPE_VARCHAR to MYSQL_TYPE_LONGLONG.
      mysql-test/r/ps_3innodb.result:
        Changed test result because SQL type of a user variable now
        more accurately represents its Item type: since Item type of a variable
        can be either STRING, INT, DECIMAL or DOUBLE, SQL type of the
        result set metadata now can be either MYSQL_TYPE_VARCHAR,
        MYSQL_TYPE_LONGLONG, MYSQL_TYPE_NEWDECIMAL or MYSQL_TYPE_DOUBLE.
        
        Previously it was always MYSQL_TYPE_VARCHAR.
        
        In particular, integer variables now have changed from
        MYSQL_TYPE_VARCHAR to MYSQL_TYPE_LONGLONG.
      mysql-test/r/ps_4heap.result:
        Changed test result because SQL type of a user variable now
        more accurately represents its Item type: since Item type of a variable
        can be either STRING, INT, DECIMAL or DOUBLE, SQL type of the
        result set metadata now can be either MYSQL_TYPE_VARCHAR,
        MYSQL_TYPE_LONGLONG, MYSQL_TYPE_NEWDECIMAL or MYSQL_TYPE_DOUBLE.
        
        Previously it was always MYSQL_TYPE_VARCHAR.
        
        In particular, integer variables now have changed from
        MYSQL_TYPE_VARCHAR to MYSQL_TYPE_LONGLONG.
      mysql-test/r/ps_5merge.result:
        Changed test result because SQL type of a user variable now
        more accurately represents its Item type: since Item type of a variable
        can be either STRING, INT, DECIMAL or DOUBLE, SQL type of the
        result set metadata now can be either MYSQL_TYPE_VARCHAR,
        MYSQL_TYPE_LONGLONG, MYSQL_TYPE_NEWDECIMAL or MYSQL_TYPE_DOUBLE.
        
        Previously it was always MYSQL_TYPE_VARCHAR.
        
        In particular, integer variables now have changed from
        MYSQL_TYPE_VARCHAR to MYSQL_TYPE_LONGLONG.
      mysql-test/r/ps_7ndb.result:
        Changed test result because SQL type of a user variable now
        more accurately represents its Item type: since Item type of a variable
        can be either STRING, INT, DECIMAL or DOUBLE, SQL type of the
        result set metadata now can be either MYSQL_TYPE_VARCHAR,
        MYSQL_TYPE_LONGLONG, MYSQL_TYPE_NEWDECIMAL or MYSQL_TYPE_DOUBLE.
        
        Previously it was always MYSQL_TYPE_VARCHAR.
        
        In particular, integer variables now have changed from
        MYSQL_TYPE_VARCHAR to MYSQL_TYPE_LONGLONG.
      mysql-test/r/sp-vars.result:
        Added test case. Previously variables could change their variable type during 
        the execution of a statement.
        Which variable type to use in the statement is specified in
        any previous statement.
      mysql-test/r/type_date.result:
        This test case result is changed because it is no longer allowed for user
        variables to change their variable type during the execution of a statement.
        The determination of which variable type to use in the statement is specified in
        any previous statement.
      mysql-test/r/user_var.result:
        This test case result is changed because it is no longer allowed for user
        variables to change their variable type during the execution of a statement.
        The determination of which variable type to use in the statement is specified in
        any previous statement.
      mysql-test/t/sp-vars.test:
        Added test case. Previously variables could change their variable type during 
        the execution of a statement.
        Which variable type to use in the statement is specified in
        any previous statement.
      mysql-test/t/type_date.test:
        This test case result is changed because it is no longer allowed for user
        variables to change their variable type during the execution of a statement.
        The determination of which variable type to use in the statement is specified in
        any previous statement.
      sql/item_func.cc:
        Adding variable m_cached_result_type to keep the variable type consistent
        during the execution of a statement.
        Previously the result type could change if the hash variable entry changed
        between statements. This caused the result set of the query to alternate
        column types in certain cases.
      sql/item_func.h:
        Adding variable m_cached_result_type to keep the variable type consistent
        during the execution of a statement.
        Previously the result type could change if the hash variable entry changed
        between statements. This caused the result set of the query to alternate
        column types in certain cases.
      755ae21b
    • unknown's avatar
      Merge vajra.(none):/opt/local/work/mysql-5.0-runtime · bf1198a9
      unknown authored
      into  vajra.(none):/opt/local/work/mysql-5.1-runtime
      
      
      mysql-test/r/sp-error.result:
        Auto merged
      mysql-test/r/sp-prelocking.result:
        Auto merged
      mysql-test/r/trigger.result:
        Auto merged
      mysql-test/t/sp-error.test:
        Auto merged
      mysql-test/t/sp-prelocking.test:
        Auto merged
      mysql-test/t/trigger.test:
        Auto merged
      sql/sql_base.cc:
        Auto merged
      bf1198a9
    • unknown's avatar
      Bug #27907 "Misleading error message when opening/locking tables" · fda27597
      unknown authored
      Adjust the check that defines the error message to be returned.
      
      
      mysql-test/r/sp-error.result:
        Update results (more accurate error code)
      mysql-test/r/sp-prelocking.result:
        Update results (more accurate error code)
      mysql-test/r/trigger.result:
        Update results (more accurate error code)
      mysql-test/t/sp-error.test:
        ER_NOT_LOCKED -> ER_NO_SUCH_TABLE
      mysql-test/t/sp-prelocking.test:
        Add a test case for Bug#27907
      mysql-test/t/trigger.test:
        ER_NOT_LOCKED -> ER_NO_SUCH_TABLE
      sql/sql_base.cc:
        Adjust the check for where-we-are for a better error message.
      fda27597
  8. 16 May, 2007 14 commits
    • unknown's avatar
      Comment fix. · d1c57f50
      unknown authored
      
      storage/ndb/include/mgmapi/mgmapi.h:
        A tiny fix to make sure MGM API does not clutter doxygen index
        page for the entire MySQL Server.
      d1c57f50
    • unknown's avatar
      Merge kpettersson@bk-internal.mysql.com:/home/bk/mysql-5.0-runtime · 7c70011e
      unknown authored
      into  adventure.(none):/home/thek/Development/cpp/mysql-5.0-runtime
      
      
      7c70011e
    • unknown's avatar
      Merge kpettersson@bk-internal.mysql.com:/home/bk/mysql-5.1-runtime · 6967dc76
      unknown authored
      into  adventure.(none):/home/thek/Development/cpp/mysql-5.1-runtime
      
      
      6967dc76
    • unknown's avatar
      Merge adventure.(none):/home/thek/Development/cpp/bug27415/my50-bug27415 · 813a1311
      unknown authored
      into  adventure.(none):/home/thek/Development/cpp/bug27415/my51-bug27415
      
      
      mysql-test/r/sp-vars.result:
        Auto merged
      mysql-test/t/sp-vars.test:
        Auto merged
      813a1311
    • unknown's avatar
      Bug#27415 Text Variables in stored procedures · d9ce3033
      unknown authored
       - Problem was reported as a SP variable using itself as 
         right value inside SUBSTR caused corruption of data. 
       - This bug could not be verified in either 5.0bk or 5.1bk
       - Added test case to prevent future regressions.
      
      
      mysql-test/r/sp-vars.result:
        Added test case for a reported regression which couldn't be
        verified.
      mysql-test/t/sp-vars.test:
        Added test case for a reported regression which couldn't be
        verified.
      d9ce3033
    • unknown's avatar
      Fix a typo. · 2480ec63
      unknown authored
      
      sql/event_data_objects.cc:
        Fix typo.
      2480ec63
    • unknown's avatar
      An attempt to fix event_bugs.test failure on Debian · b2b16294
      unknown authored
      (Bug#26338 "events_bugs.test fail on Debian")
      
      
      mysql-test/r/events_bugs.result:
        Update results.
      mysql-test/t/events_bugs.test:
        Make a stab at fixing events_bugs.test failure on Debian.
        The problem is purely in the race inherent in the test case: an
        event that was started doesn't go away fast enough and clutters the 
        processlist. This patch remove the part of the event that
        we can not wait on synchronously (there is no table 'hashed_num'
        referenced anywhere).
      b2b16294
    • unknown's avatar
      Make a stab at events_bugs.test failure under valgrind (no · 7c472868
      unknown authored
      open bug report, reproduced in the runtime team tree).
      
      
      sql/event_data_objects.cc:
        Make a stub at fixing a race in event_bugs.test under valgrind:
        read of uninitialized byte in SHOW PROCESSLIST from an event thread.
      7c472868
    • unknown's avatar
      Merge vajra.(none):/opt/local/work/mysql-5.0-21483 · c51b8905
      unknown authored
      into  vajra.(none):/opt/local/work/mysql-5.1-21483
      
      
      sql/sql_insert.cc:
        Auto merged
      c51b8905
    • unknown's avatar
      Fix a failing assert. · 75392f37
      unknown authored
      
      sql/sql_insert.cc:
        Do not access delayed thread memory without a mutex.
      75392f37
    • unknown's avatar
      Correct a merge error. · 5ac4515a
      unknown authored
      
      sql/sql_insert.cc:
        Correct a merge error (wrong declaration was used).
      5ac4515a
    • unknown's avatar
      Merge vajra.(none):/opt/local/work/mysql-5.0-21483 · 5af1df9c
      unknown authored
      into  vajra.(none):/opt/local/work/mysql-5.1-21483
      
      
      sql/sp_head.cc:
        Auto merged
      sql/sql_base.cc:
        Auto merged
      sql/sql_lex.h:
        Auto merged
      mysql-test/r/insert.result:
        Manual merge.
      mysql-test/t/insert.test:
        Manual merge.
      sql/sql_insert.cc:
        Manual merge.
      5af1df9c
    • unknown's avatar
      Merge bk-internal.mysql.com:/home/bk/mysql-5.0-runtime · 7e628372
      unknown authored
      into  vajra.(none):/opt/local/work/mysql-5.0-21483
      
      
      sql/sp_head.cc:
        Auto merged
      sql/sql_base.cc:
        Auto merged
      sql/sql_insert.cc:
        Auto merged
      sql/sql_lex.h:
        Auto merged
      7e628372
    • unknown's avatar
      A fix and a test case for · 3395c53e
      unknown authored
      Bug#21483 "Server abort or deadlock on INSERT DELAYED with another
      implicit insert"
      Also fixes and adds test cases for bugs:
      20497 "Trigger with INSERT DELAYED causes Error 1165"
      21714 "Wrong NEW.value and server abort on INSERT DELAYED to a
      table with a trigger".
      Post-review fixes.
      
      Problem:
      In MySQL INSERT DELAYED is a way to pipe all inserts into a
      given table through a dedicated thread. This is necessary for
      simplistic storage engines like MyISAM, which do not have internal
      concurrency control or threading and thus can not
      achieve efficient INSERT throughput without support from SQL layer.
      DELAYED INSERT works as follows:
      For every distinct table, which can accept DELAYED inserts and has
      pending data to insert, a dedicated thread is created to write data
      to disk. All user connection threads that attempt to
      delayed-insert into this table interact with the dedicated thread in
      producer/consumer fashion: all records to-be inserted are pushed
      into a queue of the dedicated thread, which fetches the records and 
      writes them.
      In this design, client connection threads never open or lock
      the delayed insert table.
      This functionality was introduced in version 3.23 and does not take 
      into account existence of triggers, views, or pre-locking.
      E.g. if INSERT DELAYED is called from a stored function, which,
      in turn, is called from another stored function that uses the delayed
      table, a deadlock can occur, because delayed locking by-passes
      pre-locking. Besides:
       * the delayed thread works directly with the subject table through
         the storage engine API and does not invoke triggers
       * even if it was patched to invoke triggers, if triggers,
         in turn, used other tables, the delayed thread would
         have to open and lock involved tables (use pre-locking).
       * even if it was patched to use pre-locking, without deadlock
         detection the delayed thread could easily lock out user 
         connection threads in case when the same table is used both
         in a trigger and on the right side of the insert query: 
         the delayed thread would not release locks until all inserts 
         are complete, and user connection can not complete inserts 
         without having locks on the tables used on the right side of the
         query.
      
      Solution:
      
      These considerations suggest two general alternatives for the
      future of INSERT DELAYED:
       * it is considered a full-fledged alternative to normal INSERT
       * it is regarded as an optimisation that is only relevant 
         for simplistic engines.
      Since we missed our chance to provide complete support of new
      features when 5.0 was in development, the first alternative
      currently renders infeasible.
      However, even the second alternative, which is to detect
      new features and convert DELAYED insert into a normal insert, 
      is not easy to implement.
      The catch-22 is that we don't know if the subject table has triggers
      or is a view before we open it, and we only open it in the
      delayed thread. We don't know if the query involves pre-locking
      until we have opened all tables, and we always first create
      the delayed thread, and only then open the remaining tables.
      This patch detects the problematic scenarios and converts
      DELAYED INSERT to a normal INSERT using the following approach:
       * if the statement is executed under pre-locking (e.g. from
         within a stored function or trigger) or the right
         side may require pre-locking, we detect the situation
         before creating a delayed insert thread and convert the statement
         to a conventional INSERT.
        * if the subject table is a view or has triggers, we shutdown
         the delayed thread and convert the statement to a conventional
         INSERT.
      
      
      mysql-test/r/insert.result:
        Update test results.
      mysql-test/t/insert.test:
        Add a test case for Bug#21483, Bug#20497, Bug#21714 (INSERT DELAYED
        and stored routines, triggers).
      sql/sp_head.cc:
        Upgrade lock type to TL_WRITE when computing the pre-locking set.
      sql/sql_base.cc:
        Use a new method.
      sql/sql_insert.cc:
        INSERT DELAYED and pre-locking:
        - if  under pre-locking, upgrade the lock type to TL_WRITE
        and proceed as a normal write
        - if DELAYED table has triggers, also request a lock upgrade.
        - make sure errors in the delayed thread are propagated
        correctly
      sql/sql_lex.h:
        Add a method to check if a parsed tree refers to stored
        routines.
      3395c53e
  9. 15 May, 2007 1 commit
    • unknown's avatar
      Merge vajra.(none):/opt/local/work/mysql-5.0-runtime · d71f4248
      unknown authored
      into  vajra.(none):/opt/local/work/mysql-5.1-runtime
      
      
      sql/item.cc:
        Auto merged
      sql/item_func.cc:
        Auto merged
      sql/mysql_priv.h:
        Auto merged
      sql/set_var.cc:
        Auto merged
      sql/sql_class.h:
        Auto merged
      sql/sql_insert.cc:
        Auto merged
      sql/sql_parse.cc:
        Auto merged
      sql/sql_prepare.cc:
        Auto merged
      sql/sql_yacc.yy:
        Auto merged
      mysql-test/t/disabled.def:
        Manual merge.
      d71f4248