An error occurred fetching the project authors.
  1. 27 Mar, 2009 1 commit
    • Staale Smedseng's avatar
      Bug#39953 Triggers are not working properly with multi table · 50ed1ef7
      Staale Smedseng authored
      updates
      
      Attempt to execute trigger or stored function with multi-UPDATE
      which used - but didn't update - a table that was also used by
      the calling statement led to an error. Read-only reference to
      tables used in the calling statement should be allowed.
       
      This problem was caused by the fact that check for conflicting
      use of tables in SP/triggers was performed in open_tables(),
      and in case of multi-UPDATE we didn't know exact lock type at
      this stage.
      
      We solve the problem by moving this check to lock_tables(), so
      it can be performed after exact lock types for tables used by
      multi-UPDATE are determined.
      
      
      mysql-test/r/trigger.result:
        Results for the added test case is added.
      mysql-test/t/trigger.test:
        A new test case is added, verifying correct table multi-update
        conflict resolution, both read-only and write.
      sql/sql_base.cc:
        The check for conflicting use of tables in SP/triggers is moved
        to lock_tables(), to be performed after the exact lock types
        have been determined. Also, an assert is added to open_ltable()
        to ensure this func is not used in a prelocked context.
      50ed1ef7
  2. 26 Feb, 2009 1 commit
    • Georgi Kodinov's avatar
      Bug #41354: Access control is bypassed when all columns · a9d70703
      Georgi Kodinov authored
      of a view are selected by * wildcard
      
      Backported a part of the fix for 36086 to 5.0
      
      mysql-test/r/view_grant.result:
        Bug #41354: test case
      mysql-test/t/view_grant.test:
        Bug #41354: test case
      sql/sql_acl.cc:
        Bug #41354: return table error when no access and *
      sql/sql_base.cc:
        Bug #41354: backported the check in bug 36086 to 5.0
      a9d70703
  3. 10 Feb, 2009 1 commit
  4. 27 Nov, 2008 1 commit
    • Sergey Glukhov's avatar
      Bug#37284 Crash in Field_string::type() · 1182c097
      Sergey Glukhov authored
      The bug is repeatable with latest(1.0.1) InnoDB plugin on Linux, Win,
      If MySQL is compiled with valgrind there are errors about
      using of uninitialized variable(orig_table).
      The fix is to set field->orig_table correct value.
      
      
      mysql-test/r/innodb_mysql.result:
        test result
      mysql-test/t/innodb_mysql.test:
        test case
      sql/sql_base.cc:
        set field->orig_table to 'table' value because it may be bogus and
        it leads to crash on Field_string::type() function.
      1182c097
  5. 17 Oct, 2008 1 commit
    • Georgi Kodinov's avatar
      Bug #33811: Call to stored procedure with SELECT * / RIGHT JOIN · 697b2839
      Georgi Kodinov authored
      fails after the first time
        
      Two separate problems : 
        1. When flattening joins the linked list used for name resolution 
        (next_name_resolution_table) was not updated.
        Fixed by updating the pointers when extending the table list
        
        2. The items created by expanding a * (star) as a column reference
        were marked as fixed, but no cached table was assigned to them 
        (unlike what Item_field::fix_fields does).
        Fixed by assigning a cached table (so the re-preparation is done
        faster).
        
      Note that the fix for #2 hides the fix for #1 in most cases
      (except when a table reference cannot be cached).
      
      mysql-test/r/sp.result:
        Bug #33811: test case
      mysql-test/t/sp.test:
        Bug #33811: test case
      sql/sql_base.cc:
        Bug #33811: cache the table for Item_fields created by expanding '*'
      sql/sql_select.cc:
        Bug #33811: maintain a correct name resolution chain when
        flattening joins.
      697b2839
  6. 07 Oct, 2008 1 commit
    • Gleb Shchepa's avatar
      Bug #38691: segfault/abort in ``UPDATE ...JOIN'' while · f48b42e7
      Gleb Shchepa authored
                ``FLUSH TABLES WITH READ LOCK''
      
      Concurrent execution of 1) multitable update with a
      NATURAL/USING join and 2) a such query as "FLUSH TABLES
      WITH READ LOCK" or "ALTER TABLE" of updating table led
      to a server crash.
      
      
      The mysql_multi_update_prepare() function call is optimized
      to lock updating tables only, so it postpones locking to
      the last, and if locking fails, it does cleanup of modified
      syntax structures and repeats a query analysis.  However,
      that cleanup procedure was incomplete for NATURAL/USING join
      syntax data: 1) some Field_item items pointed into freed
      table structures, and 2) the TABLE_LIST::join_columns fields
      was not reset.
      
      Major change:
        short-living Field *Natural_join_column::table_field has
        been replaced with long-living Item*.
      
      
      mysql-test/r/lock_multi.result:
        Added test case for bug #38691.
      mysql-test/t/lock_multi.test:
        Added test case for bug #38691.
      sql/item.cc:
        Bug #38691: segfault/abort in ``UPDATE ...JOIN'' while
                  ``FLUSH TABLES WITH READ LOCK''
        
        The Item_field constructor has been modified to allocate
        and copy original database/table/field names always (not
        during PS preparation/1st execution only), because
        an initialization of Item_field items with a pointer to
        short-living Field structures is a common practice.
      sql/sql_base.cc:
        Bug #38691: segfault/abort in ``UPDATE ...JOIN'' while
                  ``FLUSH TABLES WITH READ LOCK''
        
        1) Type adjustment for Natural_join_column::table_field
           (Field to Item_field);
        2) The setup_natural_join_row_types function has been
           updated to take into account new
           first_natural_join_processing flag to skip unnecessary
           reinitialization of Natural_join_column::join_columns
           during table reopening after lock_tables() failure
           (like the 'first_execution' flag for PS).
      sql/sql_lex.cc:
        Bug #38691: segfault/abort in ``UPDATE ...JOIN'' while
                  ``FLUSH TABLES WITH READ LOCK''
        
        Initialization of the new
        st_select_lex::first_natural_join_processing flag has
        been added.
      sql/sql_lex.h:
        Bug #38691: segfault/abort in ``UPDATE ...JOIN'' while
                  ``FLUSH TABLES WITH READ LOCK''
        
        The st_select_lex::first_natural_join_processing flag
        has been added to skip unnecessary rebuilding of
        NATURAL/USING JOIN structures during table reopening
        after lock_tables failure.
      sql/sql_update.cc:
        Bug #38691: segfault/abort in ``UPDATE ...JOIN'' while
                  ``FLUSH TABLES WITH READ LOCK''
        
        Extra cleanup calls have been added to reset
        Natural_join_column::table_field items.
      sql/table.cc:
        Bug #38691: segfault/abort in ``UPDATE ...JOIN'' while
                  ``FLUSH TABLES WITH READ LOCK''
        
        Type adjustment for Natural_join_column::table_field
        (Field to Item_field).
      sql/table.h:
        Bug #38691: segfault/abort in ``UPDATE ...JOIN'' while
                  ``FLUSH TABLES WITH READ LOCK''
        
        Type of the Natural_join_column::table_field field has
        been changed from Field that points into short-living
        TABLE memory to long-living Item_field that can be
        linked to (fixed) reopened table.
      f48b42e7
  7. 21 Mar, 2008 1 commit
    • unknown's avatar
      Bug #26461: Intrinsic data type bool (1 byte) redefined to BOOL (4 bytes) · cebb6727
      unknown authored
      The bool data type was redefined to BOOL (4 bytes on windows).
      Removed the #define and fixed some of the warnings that were uncovered
      by this.
      Note that the fix also disables 2 warnings :
      4800 : 'type' : forcing value to bool 'true' or 'false' (performance warning)
      4805: 'operation' : unsafe mix of type 'type' and type 'type' in operation
      
      These warnings will be handled in a separate bug, as they are performance related or bogus.
      
      Fixed to int the return type of functions that return more than 
      2 distinct values.
      
      
      CMakeLists.txt:
        Bug #26461: disable the C4800 and C4805 warnings temporarily
      include/config-win.h:
        Bug #26461: 
         - no need for this define for Windows.
         - windows C++ compilers have a bool type
      include/my_global.h:
        Bug #26461: removed bool_defined (no longer needed)
      sql/handler.h:
        Bug #26461: bool functions must return boolean values
      sql/mysql_priv.h:
        Bug #26461: fixed return type of functions that return more than
        2 distinct values.
      sql/procedure.h:
        Bug #26461: fixed return type of functions that return more than
        2 distinct values.
      sql/sql_acl.cc:
        Bug #26461: fixed return type of functions that return more than
        2 distinct values.
      sql/sql_acl.h:
        Bug #26461: fixed return type of functions that return more than
        2 distinct values.
      sql/sql_analyse.cc:
        Bug #26461: fixed return type of functions that return more than
        2 distinct values.
      sql/sql_analyse.h:
        Bug #26461: fixed return type of functions that return more than
        2 distinct values.
      sql/sql_base.cc:
        Bug #26461: fixed return type of functions that return more than
        2 distinct values.
      sql/sql_db.cc:
        Bug #26461: fixed return type of functions that return more than
        2 distinct values.
      sql/sql_delete.cc:
        Bug #26461: fixed return type of functions that return more than
        2 distinct values.
      sql/sql_load.cc:
        Bug #26461: fixed return type of functions that return more than
        2 distinct values.
      sql/sql_parse.cc:
        Bug #26461: fixed return type of functions that return more than
        2 distinct values.
      sql/sql_prepare.cc:
        Bug #26461: fixed return type of functions that return more than
        2 distinct values.
      sql/sql_update.cc:
        Bug #26461: fixed return type of functions that return more than
        2 distinct values.
      cebb6727
  8. 22 Feb, 2008 1 commit
  9. 09 Jan, 2008 1 commit
    • unknown's avatar
      Bug #33133: Views are not transparent · 06b68454
      unknown authored
      When resolving references we need to take into consideration
      the view "fields" and allow qualified access to them.
      Fixed by extending the reference resolution to process view
      fields correctly.
      
      
      mysql-test/r/func_group.result:
        Bug #33133: test case
      mysql-test/t/func_group.test:
        Bug #33133: test case
      sql/sql_base.cc:
        Bug #33133: allow qualified alias refs to view fields
      06b68454
  10. 19 Nov, 2007 1 commit
    • unknown's avatar
      Bug #31153 calling stored procedure crashes server if available memory is low · bb681dbc
      unknown authored
      When the server was out of memory it crashed because of invalid memory access.
      
      This patch adds detection for failed memory allocations and make the server
      output a proper error message.
      
      
      sql/mysqld.cc:
        Don't try to push_warning from within push_warning. It will cause a recursion
        until the stack is consumed.
        
        If my_net_init fails (for example: because of OOM) the temporary vio object 
        might have been attached to the thd object already. This will cause a double
        free on the vio object when the thd object is deleted later on and the server
        will crash.
      sql/sp_head.cc:
        Added check for out-of-memory on a 'new' operation.
        Refactored reset_lex method to return a error state code instead of void.
        Initialize the mem-root with init_sql_alloc to get a basic error handler for
        memory allocation problems. This alone won't prevent the server from crashing,
        NULL pointers have to be accounted for as well.
      sql/sp_head.h:
        Use the throw() clause in operator new, to indicate to the compiler that
        memory allocation can fail and return NULL, so that the compiler should
        generate code to check for NULL before invoking C++ constructors, to be
        crash safe.
      sql/sql_base.cc:
        Use init_sql_alloc to get basic out-of-memory error handling.
      sql/sql_lex.h:
        Use the throw() clause in operator new, to indicate to the compiler that
        memory allocation can fail and return NULL, so that the compiler should
        generate code to check for NULL before invoking C++ constructors, to be
        crash safe.
      sql/sql_prepare.cc:
        Use init_sql_alloc to get basic out-of-memory error handling.
      sql/sql_yacc.yy:
        Check for memory allocation failures where it matters.
      bb681dbc
  11. 13 Nov, 2007 1 commit
    • unknown's avatar
      Bug #31562: HAVING and lower case · 170ae2d2
      unknown authored
      The columns in HAVING can reference the GROUP BY and 
      SELECT columns. There can be "table" prefixes when
      referencing these columns. And these "table" prefixes
      in HAVING use the table alias if available.
      This means that table aliases are subject to the same
      storage rules as table names and are dependent on 
      lower_case_table_names in the same way as the table 
      names are.
      Fixed by :
      1. Treating table aliases as table names
      and make them lowercase when printing out the SQL
      statement for view persistence.
      2. Using case insensitive comparison for table 
      aliases when requested by lower_case_table_names
      
      
      mysql-test/r/lowercase_view.result:
        Bug #31562: test case
      mysql-test/t/lowercase_view.test:
        Bug #31562: test case
      sql/item.cc:
        Bug #31562: lower_case_table_name contious comparison
        when searching in GROUP BY
      sql/sql_base.cc:
        Bug #31562: lower_case_table_name contious comparison
        when searching in SELECT
      sql/sql_select.cc:
        Bug #31562: treat table aliases as table names
        and make them lowercase when printing
      170ae2d2
  12. 26 Oct, 2007 1 commit
    • unknown's avatar
      Bug#31662: 'null' is shown as type of fields for view with bad definer, breaks mysqldump · 0e700e1e
      unknown authored
      SHOW FIELDS FROM a view with no valid definer was possible (since fix
      for Bug#26817), but gave NULL as a field-type. This led to mysqldump-ing
      of such views being successful, but loading such a dump with the client
      failing. Patch allows SHOW FIELDS to give data-type of field in underlying
      table.
      
      
      mysql-test/r/information_schema_db.result:
        Fix test results: SHOW FIELDS FROM a view with no valid DEFINER
        gives us the field-type of the underlying table now rather than NULL.
      sql/sql_base.cc:
        In the case of SHOW FIELDS FROM <view>, do not require a valid
        DEFINER for determining underlying data-type like we usually do.
        This is needed for mysqldump.
      0e700e1e
  13. 09 Oct, 2007 1 commit
    • unknown's avatar
      Bug#31409 RENAME TABLE causes server crash or deadlock when used with HANDLER statements · f57813e4
      unknown authored
      This deadlock occurs when a client issues a HANDLER ... OPEN statement
      that tries to open a table that has a pending name-lock on it by another
      client that also needs a name-lock on some other table which is already
      open and associated to a HANDLER instance owned by the first client.
      The deadlock happens because the open_table() function will back-off
      and wait until the name-lock goes away, causing a circular wait if some
      other name-lock is also pending for one of the open HANDLER tables.
      
      Such situation, for example, can be easily repeated by issuing a RENAME
      TABLE command in such a way that the existing table is already open
      as a HANDLER table by another client and this client tries to open
      a HANDLER to the new table name.
      
      The solution is to allow handler tables with older versions (marked for
      flush) to be closed before waiting for the name-lock completion. This is
      safe because no other name-lock can be issued between the flush and the
      check for pending name-locks.
      
      The test case for this bug is going to be committed into 5.1 because it
      requires a test feature only avaiable in 5.1 (wait_condition).
      
      
      sql/sql_base.cc:
        Improve comments in the open_table() function, stating the importance
        of the handler tables flushing for the back-off process.
      sql/sql_handler.cc:
        Allows handler tables flushes when opening new tables in order to avoid
        potential deadlocks. Add comments explaining the importance of the flush.
      f57813e4
  14. 27 Sep, 2007 1 commit
    • unknown's avatar
      Bug #30468: column level privileges not respected when joining tables · 66f13d91
      unknown authored
      When expanding a * in a USING/NATURAL join the check for table access
      for both tables in the join was done using the grant information of the
      first one.
      Fixed by getting the grant information for the current table while 
      iterating through the columns of the join.
      
      
      mysql-test/r/grant2.result:
        Bug #30468: test case
      mysql-test/t/grant2.test:
        Bug #30468: test case
      sql/sql_acl.cc:
        Bug #30468: correctly check column grants
      sql/sql_acl.h:
        Bug #30468: correctly check column grants
      sql/sql_base.cc:
        Bug #30468: correctly check column grants
      sql/sql_insert.cc:
        Bug #30468: correctly check column grants
      66f13d91
  15. 16 Aug, 2007 2 commits
  16. 15 Aug, 2007 1 commit
    • unknown's avatar
      Fixed bug #30396. · a8f8e548
      unknown authored
      The bug caused memory corruption for some queries with top OR level
      in the WHERE condition if they contained equality predicates and 
      other sargable predicates in disjunctive parts of the condition.
      
      The corruption happened because the upper bound of the memory
      allocated for KEY_FIELD and SARGABLE_PARAM internal structures
      containing info about potential lookup keys was calculated incorrectly
      in some cases. In particular it was calculated incorrectly when the
      WHERE condition was an OR formula with disjuncts being AND formulas
      including equalities and other sargable predicates.
      
      
      mysql-test/r/select.result:
        Added a test case for bug #30396.
      mysql-test/t/select.test:
        Added a test case for bug #30396.
      sql/item_cmpfunc.h:
        Removed max_members from the COND_EQUAL class as not useful anymore.
      sql/sql_base.cc:
        Added the max_equal_elems field to the st_select_lex structure.
      sql/sql_lex.cc:
        Added the max_equal_elems field to the st_select_lex structure.
      sql/sql_lex.h:
        Added the max_equal_elems field to the st_select_lex structure.
        The field contains the maximal number of elements in multiple equalities
        built for the query conditions.
      sql/sql_select.cc:
        Fixed bug #30396.
        The bug caused memory corruption for some queries with top OR level
        in the WHERE condition if they contained equality predicates and 
        other sargable predicates in disjunctive parts of the condition.
        
        The corruption happened because the upper bound of the memory
        allocated for KEY_FIELD and SARGABLE_PARAM internal structures
        containing info about potential lookup keys was calculated incorrectly
        in some cases. In particular it was calculated incorrectly when the
        WHERE condition was an OR formula with disjuncts being AND formulas
        including equalities and other sargable predicates.
         
        The max_equal_elems field to the st_select_lex structure is used now
        to calculate the above mentioned upper bound. The field contains the
        maximal number of elements in multiple equalities built for the query
        conditions.
      a8f8e548
  17. 28 Jul, 2007 1 commit
    • unknown's avatar
      Fixed bug #29834. · 90c5621d
      unknown authored
      Using view columns by their names during an execution of
      a prepared SELECT statement or a SELECT statement inside
      a SP caused a memory leak.
      
      
      sql/sql_base.cc:
        Fixed bug #29834.
        The find_field_in_view function has been modified to
        use the execution memory root for the Item_direct_view_ref
        objects allocation at non-first executions of
        a PS/SP instead of the statement memory.
      mysql-test/t/sp.test:
        Updated test case for bug #29834.
      mysql-test/r/sp.result:
        Updated test case for bug #29834.
      90c5621d
  18. 27 Jul, 2007 1 commit
    • unknown's avatar
      A fix and a test case for Bug#24918 drop table and lock / inconsistent · 0936976e
      unknown authored
      between perm and temp tables. Review fixes.
      
      The original bug report complains that if we locked a temporary table
      with LOCK TABLES statement, we would not leave LOCK TABLES mode
      when this temporary table is dropped.
      
      Additionally, the bug was escalated when it was discovered than
      when a temporary transactional table that was previously
      locked with LOCK TABLES statement was dropped, futher actions with
      this table, such as UNLOCK TABLES, would lead to a crash.
      
      The problem originates from incomplete support of transactional temporary
      tables. When we added calls to handler::store_lock()/handler::external_lock()
      to operations that work with such tables, we only covered the normal
      server code flow and did not cover LOCK TABLES mode. 
      In LOCK TABLES mode, ::external_lock(LOCK) would sometimes be called without
      matching ::external_lock(UNLOCK), e.g. when a transactional temporary table
      was dropped. Additionally, this table would be left in the list of LOCKed 
      TABLES.
      
      The patch aims to address this inadequacy. Now, whenever an instance
      of 'handler' is destroyed, we assert that it was priorly
      external_lock(UNLOCK)-ed. All the places that violate this assert
      were fixed.
      
      This patch introduces no changes in behavior -- the discrepancy in
      behavior will be fixed when we start calling ::store_lock()/::external_lock()
      for all tables, regardless whether they are transactional or not, 
      temporary or not.
      
      
      mysql-test/r/innodb_mysql.result:
        Update test results (Bug#24918)
      mysql-test/t/innodb_mysql.test:
        Add a test case for Bug#24918
      sql/handler.h:
        Make handler::external_lock() a protected method. Backport from 5.1 its
        public wrapper handler::ha_external_lock().
        Assert that the handler is not closed if it is still locked.
      sql/lock.cc:
        In mysql_lock_tables only call lock_external() for the list of tables that
        we called store_lock() for. 
        E.g. get_lock_data() does not add non-transactional temporary tables to the
        lock list, so lock_external() should not be called for them.
        
        Use handler::ha_external_lock() instead of handler::external_lock().
        
        Add comments for mysql_lock_remove(), parameterize one strange
        side effect that it has. At least in one place where mysql_lock_remove
        is used, this side effect is not desired (DROP TABLE). The parameter
        will be dropped in 5.1, along with the side effect.
      sql/mysql_priv.h:
        Update declaration of mysql_lock_remove().
      sql/opt_range.cc:
        Deploy handler::ha_external_lock() instead of handler::external_lock()
      sql/sql_base.cc:
        When closing a temporary table, remove the table from the list of LOCKed 
        TABLES of this thread, in case it's there. 
        It's there if it is a transactional temporary table.
        Use a new declaration of mysql_lock_remove().
      sql/sql_class.h:
        Extend the comment for THD::temporary_tables.
      sql/sql_table.cc:
        Deploy handler::ha_external_lock() instead of handler::external_lock()
      0936976e
  19. 20 Jul, 2007 2 commits
    • unknown's avatar
      Remove obvious comments. · 7a99db0b
      unknown authored
      7a99db0b
    • unknown's avatar
      Bug #29644: alter table hangs if records locked in share mode · eea5c2a3
      unknown authored
      by long running transaction
      
      On Windows opened files can't be deleted. There was a special
      upgraded lock mode (TL_WRITE instead of TL_WRITE_ALLOW_READ) 
      in ALTER TABLE to make sure nobody has the table opened
      when deleting the old table in ALTER TABLE. This special mode
      was causing ALTER TABLE to hang waiting on a lock inside InnoDB.
      This special lock is no longer necessary as the server is 
      closing the tables it needs to delete in ALTER TABLE.
      Fixed by removing the special lock.
      Note that this also reverses the fix for bug 17264 that deals with
      another consequence of this special lock mode being used.
      
      
      mysql-test/r/innodb_mysql.result:
        Bug #29644: test case
      mysql-test/t/innodb_mysql.test:
        Bug #29644: test case
      sql/ha_innodb.cc:
        Bug #29644: reverse the (now excessive) fix
        for bug 17264 (but leave the test case).
      sql/sql_base.cc:
        Bug #29644: don't need a special lock mode for Win32 anymore: 
        the table is closed before the drop.
      eea5c2a3
  20. 06 Jul, 2007 1 commit
    • unknown's avatar
      Remove typedef st_table_list TABLE_LIST and always use name 'TABLE_LIST'. · 360a5ebc
      unknown authored
      The need arose when working on Bug 26141, where it became
      necessary to replace TABLE_LIST with its forward declaration in a few
      headers, and this involved a lot of s/TABLE_LIST/st_table_list/.
      Although other workarounds exist, this patch is in line
      with our general strategy of moving away from typedef-ed names.
      Sometime in future we might also rename TABLE_LIST to follow the
      coding style, but this is a huge change.
      
      
      sql/item.cc:
        st_table_list -> TABLE_LIST
      sql/item.h:
        st_table_list -> TABLE_LIST
      sql/mysql_priv.h:
        st_table_list -> TABLE_LIST
      sql/sql_base.cc:
        st_table_list -> TABLE_LIST
      sql/sql_lex.cc:
        st_table_list -> TABLE_LIST
      sql/sql_lex.h:
        st_table_list -> TABLE_LIST
      sql/sql_select.cc:
        st_table_list -> TABLE_LIST
      sql/sql_show.cc:
        st_table_list -> TABLE_LIST
      sql/sql_udf.h:
        Was not needed.
      sql/table.cc:
        st_table_list -> TABLE_LIST
      sql/table.h:
        st_table_list -> TABLE_LIST
      360a5ebc
  21. 03 Jun, 2007 1 commit
    • unknown's avatar
      Bug #26162: Trigger DML ignores low_priority_updates setting · f9a41f9f
      unknown authored
        
      The value of "low-priority-updates" option and the LOW PRIORITY
      prefix was taken into account at parse time.
      This caused triggers (among others) to ignore this flag (if
      supplied for the DML statement).
      Moved reading of the LOW_PRIORITY flag at run time.
      Fixed an incosistency when handling
      SET GLOBAL LOW_PRIORITY_UPDATES : now it is in effect for
      delayed INSERTs.
      Tested by checking the effect of LOW_PRIORITY flag via a 
      trigger.
      
      
      include/thr_lock.h:
        Bug #26162: moved reading of the LOW PRIORITY flag at run time
      mysql-test/r/trigger.result:
        Bug #26162: test case
      mysql-test/t/trigger.test:
        Bug #26162: test case
      sql/set_var.cc:
        Bug #26162: fixed the handling of the "low-priority-updates" option
      sql/sql_base.cc:
        Bug #26162: moved reading of the LOW PRIORITY flag at run time
      sql/sql_yacc.yy:
        Bug #26162: moved reading of the LOW PRIORITY flag at run time
      f9a41f9f
  22. 23 May, 2007 1 commit
    • unknown's avatar
      Bug#27563: Stored functions and triggers wasn't throwing an error when killed. · 1734b4e9
      unknown authored
      If a stored function or a trigger was killed it had aborted but no error
      was thrown. This allows the caller statement to continue without a notice.
      This may lead to a wrong data being inserted/updated to/deleted as in such
      cases the correct result of a stored function isn't guaranteed. In the case
      of triggers it allows the caller statement to ignore kill signal and to
      waste time because of re-evaluation of triggers that always will fail
      because thd->killed flag is still on.
      
      Now the Item_func_sp::execute() and the sp_head::execute_trigger() functions
      check whether a function or a trigger were killed during execution and
      throws an appropriate error if so.
      Now the fill_record() function stops filling record if an error was reported
      through thd->net.report_error.
      
      
      sql/item_func.cc:
        Bug#27563: Stored functions and triggers wasn't throwing an error when killed.
        Now the Item_func_sp::execute() function checks whether a trigger was killed
        during execution and throws an appropriate error if so.
      sql/sp_head.cc:
        Bug#27563: Stored functions and triggers wasn't throwing an error when killed.
        Now the sp_head::execute_trigger() function checks whether a function was
        killed during execution and throws an appropriate error if so.
      sql/sql_base.cc:
        Bug#27563: Stored functions and triggers wasn't throwing an error when killed.
        Now the fill_record() function stops filling record if an error was reported
        through thd->net.report_error.
      mysql-test/r/kill.result:
        Added a test case for the bug#27563: Stored functions and triggers wasn't
        throwing an error when killed.
      mysql-test/t/kill.test:
        Added a test case for the bug#27563: Stored functions and triggers wasn't
        throwing an error when killed.
      1734b4e9
  23. 22 May, 2007 1 commit
    • unknown's avatar
      Bug #28476: force index on a disabled myisam index gives error 124 · 3332b801
      unknown authored
      When processing the USE/FORCE index hints
      the optimizer was not checking if the indexes 
      specified are enabled (see ALTER TABLE).
      Fixed by:
       Backporting the fix for bug 20604 to 5.0
      
      
      mysql-test/r/key.result:
        Test for BUG 20604.
        The important part of the test is the explain output that 
        tests what indexes are used.
      mysql-test/r/myisam.result:
        Bug #28476: test cases
      mysql-test/t/key.test:
        Bug 20604: 
        The minimal test case that reveals the bug. The optimizer for 
        aggregates relies on keys disabled with ALTER TABLE ... DISABLE KEYS
        not being in the set TABLE::keys_in_use_for_query.
        When the execution engine tries to use a disabled index, MyISAM
        returns an error.
      mysql-test/t/myisam.test:
        Bug #28476: test cases
      sql/sql_base.cc:
        Bug #28476: 
         - Ignore disabled indexes in USE/FORCE index
      sql/sql_select.cc:
        Bug 20604 : The intersection operation between table->s->keys_in_use 
        and table->keys_in_use_for_query is no longer necessary.
        We can trust that the latter is a subset of the former.
      sql/table.h:
        Bug 20604:
        Added comments to TABLE_SHARE::keys_in_use and
        TABLE::keys_in_use_for_query.
      3332b801
  24. 18 May, 2007 1 commit
    • 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
  25. 16 May, 2007 2 commits
    • unknown's avatar
      Backport of TIME->MYSQL_TIME / Y2K fixset · b5e4f54a
      unknown authored
         
      Made year 2000 handling more uniform
      Removed year 2000 handling out from calc_days()
      The above removes some bugs in date/datetimes with year between 0 and 200
      Now we get a note when we insert a datetime value into a date column
      For default values to CREATE, don't give errors for warning level NOTE
      Fixed some compiler failures
      Added library ws2_32 for windows compilation (needed if we want to compile with IOCP support)
      Removed duplicate typedef TIME and replaced it with MYSQL_TIME
      
      Better (more complete) fix for: Bug#21103 "DATE column not compared as DATE"
      Fixed properly Bug#18997 "DATE_ADD and DATE_SUB perform year2K autoconversion magic on 4-digit year value"
      Fixed Bug#23093 "Implicit conversion of 9912101 to date does not match cast(9912101 as date)"
       
      
      
      include/my_time.h:
        Removed not used define YY_MAGIC_BELOW
        Added prototype for year_2000_handling()
      mysql-test/r/date_formats.result:
        Updated results (fixed bug in date_format() with year < 99
      mysql-test/r/func_sapdb.result:
        Added more testing of make_date()
      mysql-test/r/ps_2myisam.result:
        Now we get a note when we insert a datetime value into a date column
      mysql-test/r/ps_3innodb.result:
        Now we get a note when we insert a datetime value into a date column
      mysql-test/r/ps_4heap.result:
        Now we get a note when we insert a datetime value into a date column
      mysql-test/r/ps_5merge.result:
        Now we get a note when we insert a datetime value into a date column
      mysql-test/r/ps_7ndb.result:
        Now we get a note when we insert a datetime value into a date column
      mysql-test/r/strict.result:
        zero-year in str_to_date() throws warning in strict
      mysql-test/r/type_date.result:
        Added test for date conversions
      mysql-test/r/type_datetime.result:
        Added testcase for datetime to date conversion.
      mysql-test/t/date_formats.test:
        Added testing of dates < 200
      mysql-test/t/func_sapdb.test:
        More testing of makedate()
      mysql-test/t/type_date.test:
        Added test for date conversions
      mysql-test/t/type_datetime.test:
        Added testcase for datetime to date conversion
      sql/field.cc:
        Give note if we insert a datetime value in a date field
        Don't give notes if we are doing internal test conversions (like from convert_constant_item())
        More documentation (store functions can now return '3' to inform that the function did return a NOTE (not warning or error))
        Revert some changes in Field_newdate::store() to get more optimal code
        Field::set_warning() will now ignore notes if CHECK_FIELD_IGNORE is set.
        New parameters to make_truncated_value_warning()
      sql/field.h:
        Give note if we insert a datetime value in a date field
        Don't give notes if we are doing internal test conversions (like from convert_constant_item())
        More documentation (store functions can now return '3' to inform that the function did return a NOTE (not warning or error))
        Revert some changes in Field_newdate::store() to get more optimal code
        Field::set_warning() will now ignore notes if CHECK_FIELD_IGNORE is set.
        New parameters to make_truncated_value_warning()
      sql/item.cc:
        Give note if we insert a datetime value in a date field
        Don't give notes if we are doing internal test conversions (like from convert_constant_item())
        More documentation (store functions can now return '3' to inform that the function did return a NOTE (not warning or error))
        Revert some changes in Field_newdate::store() to get more optimal code
        Field::set_warning() will now ignore notes if CHECK_FIELD_IGNORE is set.
        New parameters to make_truncated_value_warning()
      sql/item.h:
        TIME -> MYSQL_TIME
      sql/item_cmpfunc.cc:
        Don't print notes in convert_constant_item()
      sql/item_func.h:
        TIME -> MYSQL_TIME
      sql/item_timefunc.cc:
        New parameters to make_truncated_value_warning()
        Moved year 2000 handling out from calc_days()
      sql/item_timefunc.h:
        TIME -> MYSQL_TIME
      sql/my_decimal.cc:
        TIME -> MYSQL_TIME
      sql/my_decimal.h:
        TIME -> MYSQL_TIME
      sql/mysql_priv.h:
        Added error level to make_truncated_value_warning()
      sql/protocol.cc:
        TIME -> MYSQL_TIME
      sql/protocol.h:
        TIME -> MYSQL_TIME
      sql/sp.cc:
        TIME -> MYSQL_TIME
      sql/sql_base.cc:
        Make testing of result value of save_in_field() uniform
      sql/sql_class.h:
        TIME -> MYSQL_TIME
      sql/sql_show.cc:
        TIME -> MYSQL_TIME
      sql/structs.h:
        TIME -> MYSQL_TIME
      sql/time.cc:
        Added error level to make_truncated_value_warning()
      sql/tztime.cc:
        TIME -> MYSQL_TIME
      sql/tztime.h:
        TIME -> MYSQL_TIME
      sql/unireg.cc:
        For default values to CREATE, don't give errors for warning level NOTE
        (Fixed failed CREATE when we give a datetime value to a date field)
      sql-common/my_time.c:
        Added year_2000_handling()
        Removed year 2000 handling from calc_daynr()
      b5e4f54a
    • 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
  26. 11 May, 2007 1 commit
    • unknown's avatar
      Fix for: · c5a82455
      unknown authored
        Bug #20662 "Infinite loop in CREATE TABLE IF NOT EXISTS ... SELECT
                    with locked tables"
        Bug #20903 "Crash when using CREATE TABLE .. SELECT and triggers"
        Bug #24738 "CREATE TABLE ... SELECT is not isolated properly"
        Bug #24508 "Inconsistent results of CREATE TABLE ... SELECT when
                    temporary table exists"
       
      Deadlock occured when one tried to execute CREATE TABLE IF NOT
      EXISTS ... SELECT statement under LOCK TABLES which held
      read lock on target table.
      Attempt to execute the same statement for already existing
      target table with triggers caused server crashes.
      Also concurrent execution of CREATE TABLE ... SELECT statement
      and other statements involving target table suffered from
      various races (some of which might've led to deadlocks).
      Finally, attempt to execute CREATE TABLE ... SELECT in case
      when a temporary table with same name was already present
      led to the insertion of data into this temporary table and
      creation of empty non-temporary table.
       
      All above problems stemmed from the old implementation of CREATE
      TABLE ... SELECT in which we created, opened and locked target
      table without any special protection in a separate step and not
      with the rest of tables used by this statement.
      This underminded deadlock-avoidance approach used in server
      and created window for races. It also excluded target table
      from prelocking causing problems with trigger execution.
        
      The patch solves these problems by implementing new approach to
      handling of CREATE TABLE ... SELECT for base tables.
      We try to open and lock table to be created at the same time as
      the rest of tables used by this statement. If such table does not
      exist at this moment we create and place in the table cache special
      placeholder for it which prevents its creation or any other usage
      by other threads.
      
      We still use old approach for creation of temporary tables.
      
      Also note that we decided to postpone introduction of some tests
      for concurrent behaviour of CREATE TABLE ... SELECT till 5.1.
      The main reason for this is absence in 5.0 ability to set @@debug
      variable at runtime, which can be circumvented only by using several
      test files with individual .opt files. Since the latter is likely
      to slowdown test-suite unnecessary we chose not to push this tests
      into 5.0, but run them manually for this version and later push
      their optimized version into 5.1
      
      
      mysql-test/r/create.result:
        Extended test coverage for CREATE TABLE ... SELECT. In particular added
        tests for bug #24508 "Inconsistent results of CREATE TABLE ... SELECT
        when temporary table exists" and bug #20662 "Infinite loop in CREATE
        TABLE IF NOT EXISTS ... SELECT with locked tables".
      mysql-test/r/trigger.result:
        Added test case for bug #20903 "Crash when using CREATE TABLE .. SELECT
        and triggers"
      mysql-test/t/create.test:
        Extended test coverage for CREATE TABLE ... SELECT. In particular added
        tests for bug #24508 "Inconsistent results of CREATE TABLE ... SELECT
        when temporary table exists" and bug #20662 "Infinite loop in CREATE
        TABLE IF NOT EXISTS ... SELECT with locked tables".
      mysql-test/t/trigger.test:
        Added test case for bug #20903 "Crash when using CREATE TABLE .. SELECT
        and triggers"
      sql/lock.cc:
        Now for creation of name-lock placeholder in lock_table_name() we use
        auxiliary function table_cache_insert_placeholder().
      sql/mysql_priv.h:
        Made build_table_path() function available outside of sql_table.cc file.
        reopen_name_locked_table() now has 3rd argument which controls linking
        in of table being opened into THD::open_tables (this is useful in
        cases when placeholder used for name-locking is already linked into
        this list).
        Added declaration of auxiliary function table_cache_insert_placeholder()
        which is used for creation of table placeholders for name-locking.
        Added declaration of table_cache_has_open_placeholder() function which
        can be used for checking if table cache contains an open placeholder for
        the table and if this placeholder was created by another thread.
        (This function is needed only in 5.0 where we use it in various versions
         of CREATE TABLE in order to protect it from concurrent CREATE TABLE
         ... SELECT operations for the table. Starting from 5.1 we use different
         approach so it is going to be removed there).
        Made close_old_data_files() static within sql_base.cc file. 
        Added auxiliary drop_open_table() routine.
        Moved declaration of refresh_version to table.h header to make it
        accessible from inline methods of TABLE class.
        MYSQL_OPEN_IGNORE_LOCKED_TABLES flag is no longer used. Instead
        MYSQL_OPEN_TEMPORARY_ONLY option was added.
      sql/sql_base.cc:
        Added support for the new approach to the handling of CREATE TABLE
        ... SELECT for base tables.
        
        Now we try to open and lock table to be created at the same time as
        the rest of tables used by this statement. If such table does not
        exist at this moment we create and place in the table cache special
        placeholder for it which prevents its creation or any other usage
        by other threads.
        
        Note significant distinctions of this placeholder from the placeholder
        used for normal name-lock: 1) It is treated like open table by other
        name-locks so it does not allow name-lock taking operations like DROP
        TABLE or RENAME TABLE to proceed. 2) it is linked into THD::open_tables
        list and automatically removed during close_thread_tables() call.
        
        open_tables():
          Implemented logic described above. To do this added
          auxiliary check_if_table_exists() function.
          Removed support for MYSQL_OPEN_IGNORE_LOCKED_TABLES option
          which is no longer used.
          Added MYSQL_OPEN_TEMPORARY_ONLY which is used to restrict
          search for temporary tables only.
        close_cached_tables()/close_thread_table()/reopen_tables()/
        close_old_data_files()/table_is_used()/remove_table_from_cache():
          Added support for open placeholders (note that we also use them
          when we need to re-open tables during flush).
        Added auxiliary drop_open_table() routine.
        reopen_name_locked_table():
          Now has 3rd argument which controls linking in of table being
          opened into THD::open_tables (this is useful in cases when
          placeholder used for name-locking is already linked into
          this list).
        Added auxiliary table_cache_insert_placeholder() routine which
        simplifies creation of placeholders used for name-locking.
        Added table_cache_has_open_placeholder() function which can be
        used for checking if table cache contains an open placeholder for
        the table and if this placeholder was created by another thread.
        (This function is needed only in 5.0 where we use it in various versions
         of CREATE TABLE in order to protect it from concurrent CREATE TABLE
         ... SELECT operations for the table. Starting from 5.1 we use different
         approach so it is going to be removed there).
      sql/sql_handler.cc:
        Adjusted mysql_ha_mark_tables_for_reopen() routine to properly
        handle placeholders which now can be linked into open tables
        list.
      sql/sql_insert.cc:
        Introduced new approach to handling of base tables in CREATE TABLE
        ... SELECT statement.
        
        Now we try to open and lock table to be created at the same time as
        the rest of tables used by this statement. If such table does not
        exist at this moment we create and place in the table cache special
        placeholder for it which prevents its creation or any other usage
        by other threads. By doing this we avoid races which existed with
        previous approach in which we created, opened and locked target in
        separate step without any special protection.
        This also allows properly calculate prelocking set in cases when
        target table already exists and has some on insert triggers.
          
        Note that we don't employ the same approach for temporary tables
        (this is okay as such tables are unaffected by other threads).
        
        Changed create_table_from_items() and select_create methods to
        implement this approach.
      sql/sql_parse.cc:
        The new approach to handling of CREATE TABLE ... SELECT for
        base tables assumes that all tables (including table to be
        created) are opened and (or) locked at the same time.
        So in cases when we create base table we have to pass to
        open_and_lock_tables() table list which includes target table.
      sql/sql_prepare.cc:
        The new approach to handling of CREATE TABLE ... SELECT for
        base tables assumes that all tables (including table to be
        created) are opened and (or) locked at the same time.
        So in cases when we create base table we have to pass to
        open_and_lock_tables() table list which includes target table.
      sql/sql_table.cc:
        Now mysql_create_table_internal(), mysql_create_like_table() and
        mysql_alter_table() not only check that destination table doesn't
        exist on disk but also check that there is no create placeholder
        in table cache for it (i.e. there is no CREATE TABLE ... SELECT
        operation in progress for it). Note that starting from 5.1 we
        use different approach in order to to protect CREATE TABLE ... SELECT
        from concurrent CREATE TABLE (ALTER TABLE ... RENAME) operations,
        the latter simply take name-locks on table before its creation
        (on target table name before renaming).
        
        Also made build_table_path() available from other files and
        asjusted calls to reopen_name_locked_table(), which now takes
        extra argument, which controls linking of open table into
        THD::open_tables list.
      sql/sql_trigger.cc:
        reopen_name_locked_tables() now has one more argument which controls
        linking of opened table into the THD::open_tables list.
      sql/sql_yacc.yy:
        The new approach to handling of CREATE TABLE ... SELECT statement
        for base tables assumes that all tables including table to be
        created are open and (or) locked at the same time. Therefore
        we need to set correct lock for target table.
      sql/table.h:
        Moved declaration of refresh_version variable from mysql_priv.h
        to make it accessible from inline methods of TABLE class. 
        Renamed TABLE::locked_by_flush member to open_placeholder since
        now it is also used for taking exclusive name-lock and not only
        by flush. 
        Introduced TABLE::is_name_opened() helper method which can be used
        to distinguish TABLE instances corresponding to open tables or
        placeholders for them from closed instances (e.g. due to their old
        version). Also introduced TABLE::needs_reopen_or_name_lock() helper
        which allows to check if TABLE instance corresponds to outdated
        version of table or to name-lock placeholder.
        Introduced TABLE_LIST::create member which marks elements of
        table list corresponds to the table to be created.
        Adjusted TABLE_LIST::placeholder() method to take into account 
        name-lock placeholders for tables to be created (this, for example,
        allows to properly handle such placeholders in lock_tables()).
      c5a82455
  27. 24 Apr, 2007 1 commit
    • unknown's avatar
      Bug#27874: Non-grouped columns are allowed by * in ONLY_FULL_GROUP_BY mode. · 3ffdeef0
      unknown authored
      When fields are inserted instead of * in the select list they were not marked
      for check for the ONLY_FULL_GROUP_BY mode.
      
      The Field_iterator_table::create_item() function now marks newly created
      items for check when in the ONLY_FULL_GROUP_BY mode.
      The setup_wild() and the insert_fields() functions now maintain the
      cur_pos_in_select_list counter for the ONLY_FULL_GROUP_BY mode.
      
      
      sql/sql_base.cc:
        Bug#27874: Non-grouped columns are allowed by * in ONLY_FULL_GROUP_BY mode.
        The setup_wild() and the insert_fields() functions now maintain the
        cur_pos_in_select_list counter for the ONLY_FULL_GROUP_BY mode.
      sql/table.cc:
        Bug#27874: Non-grouped columns are allowed by * in ONLY_FULL_GROUP_BY mode.
        The Field_iterator_table::create_item() function now marks newly created
        items for check when in the ONLY_FULL_GROUP_BY mode.
      mysql-test/r/group_by.result:
        Added a test case for the bug#27874: Non-grouped columns are allowed by * in ONLY_FULL_GROUP_BY mode.
      mysql-test/t/group_by.test:
        Added a test case for the bug#27874: Non-grouped columns are allowed by * in ONLY_FULL_GROUP_BY mode.
      3ffdeef0
  28. 30 Mar, 2007 1 commit
    • unknown's avatar
      Bug#23233: 0 as LAST_INSERT_ID() after INSERT .. ON DUPLICATE in the · 86a0ffdd
      unknown authored
      NO_AUTO_VALUE_ON_ZERO mode.
      
      In the NO_AUTO_VALUE_ON_ZERO mode the table->auto_increment_field_not_null
      variable is used to indicate that a non-NULL value was specified by the user
      for an auto_increment column. When an INSERT .. ON DUPLICATE updates the
      auto_increment field this variable is set to true and stays unchanged for the
      next insert operation. This makes the next inserted row sometimes wrongly have
      0 as the value of the auto_increment field.
      
      Now the fill_record() function resets the table->auto_increment_field_not_null
      variable before filling the record.
      The table->auto_increment_field_not_null variable is also reset by the
      open_table() function for a case if we missed some auto_increment_field_not_null
      handling bug.
      Now the table->auto_increment_field_not_null is reset at the end of the
      mysql_load() function.
      
      Reset the table->auto_increment_field_not_null variable after each
      write_row() call in the copy_data_between_tables() function.
      
      
      
      
      sql/field_conv.cc:
        Bug#23233: 0 as LAST_INSERT_ID() after INSERT .. ON DUPLICATE in the 
        NO_AUTO_VALUE_ON_ZERO mode.
        A comment is corrected.
      sql/handler.cc:
        Bug#23233: 0 as LAST_INSERT_ID() after INSERT .. ON DUPLICATE in the 
        NO_AUTO_VALUE_ON_ZERO mode.
        Now the handler::update_auto_increment() function doesn't reset the
        table->auto_increment_field_not_null variable as it is done in the
        fill_record() function.
      sql/sql_base.cc:
        Bug#23233: 0 as LAST_INSERT_ID() after INSERT .. ON DUPLICATE in the 
        NO_AUTO_VALUE_ON_ZERO mode.
        Now the fill_record() function resets the table->auto_increment_field_not_null
        variable before filling the record.
        The table->auto_increment_field_not_null variable is also reset by the
        open_table() function for a case if we missed some auto_increment_field_not_null
        handling bug.
      sql/sql_insert.cc:
        Bug#23233: 0 as LAST_INSERT_ID() after INSERT .. ON DUPLICATE in the
        NO_AUTO_VALUE_ON_ZERO mode.
        Now the the table->auto_increment_field_not_null is reset at the end of the
        mysql_insert() an in the select_insert class destructor.
      sql/sql_load.cc:
        Bug#23233: 0 as LAST_INSERT_ID() after INSERT .. ON DUPLICATE in the 
        NO_AUTO_VALUE_ON_ZERO mode.
        Now the table->auto_increment_field_not_null is reset at the end of the
        mysql_load() function.
      sql/sql_table.cc:
        Bug#23233: 0 as LAST_INSERT_ID() after INSERT .. ON DUPLICATE in the
        NO_AUTO_VALUE_ON_ZERO mode.
        Reset the table->auto_increment_field_not_null variable after each
        write_row() call in the copy_data_between_tables() function.
      sql/table.h:
        Bug#23233: 0 as LAST_INSERT_ID() after INSERT .. ON DUPLICATE in the
        NO_AUTO_VALUE_ON_ZERO mode.
        A comment added.
      mysql-test/r/insert_update.result:
        Added the test case for the bug#23233: 0 as LAST_INSERT_ID() after
        INSERT .. ON DUPLICATE in the NO_AUTO_VALUE_ON_ZERO mode.
      mysql-test/t/insert_update.test:
        Added the test case for the bug#23233: 0 as LAST_INSERT_ID() after
        INSERT .. ON DUPLICATE in the NO_AUTO_VALUE_ON_ZERO mode.
      86a0ffdd
  29. 23 Mar, 2007 1 commit
    • unknown's avatar
      Bug #26817: mysqldump fails to backup database containing view with invalid definer · b765a8af
      unknown authored
      give some leeway on required permissions for SHOW FIELDS on views so
      an unknonwn DEFINER will no longer break mysqldump
      
      
      client/client_priv.h:
        Bug #26817: mysqldump fails to backup database containing view with invalid definer
        
        New option for mysqldump: redirect stderr to file ("2> for Windows")
      client/mysqldump.c:
        Bug #26817: mysqldump fails to backup database containing view with invalid definer
        
        New option for mysqldump: redirect stderr to file ("2> for Windows")
      mysql-test/r/information_schema_db.result:
        Bug #26817: mysqldump fails to backup database containing view with invalid definer
        
        New option for mysqldump: redirect stderr to file ("2> for Windows")
      mysql-test/t/information_schema_db.test:
        Bug #26817: mysqldump fails to backup database containing view with invalid definer
        
        New option for mysqldump: redirect stderr to file ("2> for Windows")
      sql/sql_base.cc:
        Bug #26817: mysqldump fails to backup database containing view with invalid definer
        
        be a little more lenient for SHOW FIELDS FROM
      sql/sql_parse.cc:
        Bug #26817: mysqldump fails to backup database containing view with invalid definer
        
        be a little more lenient for SHOW FIELDS FROM on views on views
      sql/sql_view.cc:
        Bug #26817: mysqldump fails to backup database containing view with invalid definer
        
        give SHOW FIELDS the same perks as SHOW CREATE
      sql/table.cc:
        Bug #26817: mysqldump fails to backup database containing view with invalid definer
        
        give SHOW FIELDS the same perks as SHOW CREATE
      b765a8af
  30. 22 Mar, 2007 2 commits
    • unknown's avatar
      Fixed bug #27229: crash when a set function aggregated in outer · 1f8bdbe4
      unknown authored
      context was used as an argument of GROUP_CONCAT.
      Ensured correct setting of the depended_from field in references
      generated for set functions aggregated in outer selects.
      A wrong value of this field resulted in wrong maps returned by 
      used_tables() for these references.
      Made sure that a temporary table field is added for any set function
      aggregated in outer context when creation of a temporary table is 
      needed to execute the inner subquery. 
      
      
      mysql-test/r/subselect.result:
        Added a test case for bug #27229.
      mysql-test/t/subselect.test:
        Added a test case for bug #27229.
      sql/item.cc:
        Fixed bug #27229: crash when a set function aggregated in outer
        context was used as an argument of GROUP_CONCAT.
        Ensured correct setting of the depended_from field in references
        generated for set functions aggregated in outer selects.
      sql/item_sum.cc:
        Fixed bug #27229: crash when a set function aggregated in outer
        context was used as an argument of GROUP_CONCAT.
        Added the field aggr_sel to the objects of the class Item_sum.
        In any Item_sum object created for a set function this field 
        has to contain a pointer to the select where the set function
        is aggregated.
      sql/item_sum.h:
        Fixed bug #27229: crash when a set function aggregated in outer
        context was used as an argument of GROUP_CONCAT.
        Added the field aggr_sel to the objects of the class Item_sum.
        In any Item_sum object created for a set function this field 
        has to contain a pointer to the select where the set function
        is aggregated.
        Added a method that says whether a set function is aggregated
        in outer context and, if so, returns the aggregating select.
        Removed the field nest_level_tables_count introduced by the
        patch for bug 24484 as aggr_sel->join->tables contains the
        sane number.
      sql/sql_base.cc:
        Fixed bug #27229: crash when a set function aggregated in outer
        context was used as an argument of GROUP_CONCAT.
        Added the field aggr_sel to the objects of the class Item_sum.
        Removed changes introduced by the patch for bug 24484 as 
        the field leaf_count of the THD class is not used anymore.
      sql/sql_class.h:
        Fixed bug #27229: crash when a set function aggregated in outer
        context was used as an argument of GROUP_CONCAT.
        Added the field aggr_sel to the objects of the class Item_sum.
        Removed changes introduce by the patch for bug 24484 as 
        the field leaf_count of the THD class is not used anymore.
      sql/sql_insert.cc:
        Fixed bug #27229: crash when a set function aggregated in outer
        context was used as an argument of GROUP_CONCAT.
        Added the field aggr_sel to the objects of the class Item_sum.
        Removed changes introduce by the patch for bug 24484 as 
        the field leaf_count of the THD class is not used anymore.
      sql/sql_select.cc:
        Fixed bug #27229: crash when a set function aggregated in outer
        context was used as an argument of GROUP_CONCAT.
        When creating a temporary table a field is added in it for any 
        set function aggregated in outer context.
      1f8bdbe4
    • unknown's avatar
      - renaming TMP_TABLE to NON_TRANSACTIONAL_TMP_TABLE because this is · 685d21b7
      unknown authored
      what it actually means (Monty approved the renaming)
      - correcting description of transaction_alloc command-line options
      (our manual is correct)
      - fix for a failure of rpl_trigger.
      
      
      mysql-test/t/rpl_misc_functions.test:
        test was cleaning up only on slave, but it's also needed on master,
        otherwise it influences rpl_trigger.test
      sql/lock.cc:
        clearer name
      sql/mysqld.cc:
        I checked the code that those two variables are not about binlogging
        but about the size of the transaction's memroot which is used
        to create savepoint structures and to store list of tables to be invalidated
        (for NDB). The manual has a correct description, no need to fix it.
      sql/sql_base.cc:
        clearer name
      sql/sql_derived.cc:
        clearer name
      sql/sql_select.cc:
        clearer name
      sql/table.h:
        clearer name: TMP_TABLE is used for non-transactional tables.
      685d21b7
  31. 20 Mar, 2007 1 commit
    • unknown's avatar
      Bug #24484: · 9c89dd65
      unknown authored
      To correctly decide which predicates can be evaluated with a given table
      the optimizer must know the exact set of tables that a predicate depends 
      on. If that mask is too wide (refer to non-existing tables) the optimizer
      can erroneously skip a predicate.
      One such case of wrong table usage mask were the aggregate functions.
      The have a all-1 mask (meaning depend on all tables, including non-existent
      ones).
      Fixed by making a real used_tables mask for the aggregates. The mask is
      constructed in the following way :
      1. OR the table dependency masks of all the arguments of the aggregate.
      2. If all the arguments of the function are from the local name resolution 
        context and it is evaluated in the same name resolution
        context where it is referenced all the tables from that name resolution 
        context are OR-ed to the dependency mask. This is to denote that an
        aggregate function depends on the number of rows it processes.
      3. Handle correctly the case of an aggregate function optimization (such that
        the aggregate function can be pre-calculated and made a constant).
      
      Made sure that an aggregate function is never a constant (unless subject of a 
      specific optimization and pre-calculation).  
      
      One other flaw was revealed and fixed in the process : references were 
      not calling the recalculation method for used_tables of their targets.
      
      
      mysql-test/r/subselect3.result:
        Bug #24484: test case
      mysql-test/t/subselect3.test:
        Bug #24484: test case
      sql/item.h:
        Bug #24484: Item_ref must update the used tables.
      sql/item_sum.cc:
        Bug #24484: correct calculation of used_tables for aggregates.
      sql/item_sum.h:
        Bug #24484: correct calculation of used_tables for aggregates.
      sql/opt_range.cc:
        Bug #24484: fixed ref resolution in loose index scan
      sql/sql_base.cc:
        Bug #24484: moved counting of leaf tables inside 
        setup_tables_and_check_access.
      sql/sql_class.h:
        Bug #24484: changed table count to more narrow type.
      sql/sql_insert.cc:
        Bug #24484: moved counting of leaf tables inside 
        setup_tables_and_check_access. Substract the first
        table (and its subtables) of an INSERT statement
        from leaf_count.
      sql/sql_select.cc:
        Bug #24484: correct check for aggregates
      9c89dd65
  32. 09 Mar, 2007 1 commit
    • unknown's avatar
      Polishing: use constants instead of magic numbers. · a0521cd7
      unknown authored
      include/my_global.h:
        Introduce constants to be used instead of magic numbers.
      sql/field.cc:
        Polishing: use contants instead of magic numbers.
      sql/ha_innodb.cc:
        Polishing: use contants instead of magic numbers.
      sql/handler.cc:
        Polishing: use contants instead of magic numbers.
      sql/item.cc:
        Polishing: use contants instead of magic numbers.
      sql/item.h:
        Polishing: use contants instead of magic numbers.
      sql/item_func.cc:
        Polishing: use contants instead of magic numbers.
      sql/item_subselect.cc:
        Polishing: use contants instead of magic numbers.
      sql/log_event.cc:
        Polishing: use contants instead of magic numbers.
      sql/sql_base.cc:
        Polishing: use contants instead of magic numbers.
      sql/sql_select.cc:
        Polishing: use contants instead of magic numbers.
      sql/sql_show.cc:
        Polishing: use contants instead of magic numbers.
      sql/sql_table.cc:
        Polishing: use contants instead of magic numbers.
      a0521cd7
  33. 06 Mar, 2007 1 commit
    • unknown's avatar
      Bug#8407 (Stored functions/triggers ignore exception handler) · 266a7fff
      unknown authored
      Bug 18914 (Calling certain SPs from triggers fail)
      Bug 20713 (Functions will not not continue for SQLSTATE VALUE '42S02')
      Bug 21825 (Incorrect message error deleting records in a table with a
        trigger for inserting)
      Bug 22580 (DROP TABLE in nested stored procedure causes strange dependency
        error)
      Bug 25345 (Cursors from Functions)
      
      
      This fix resolves a long standing issue originally reported with bug 8407,
      which affect the behavior of Stored Procedures, Stored Functions and Trigger
      in many different ways, causing symptoms reported by all the bugs listed.
      In all cases, the root cause of the problem traces back to 8407 and how the
      server locks tables involved with sub statements.
      
      Prior to this fix, the implementation of stored routines would:
      - compute the transitive closure of all the tables referenced by a top level
      statement
      - open and lock all the tables involved
      - execute the top level statement
      "transitive closure of tables" means collecting:
      - all the tables,
      - all the stored functions,
      - all the views,
      - all the table triggers
      - all the stored procedures
      involved, and recursively inspect these objects definition to find more
      references to more objects, until the list of every object referenced does
      not grow any more.
      This mechanism is known as "pre-locking" tables before execution.
      The motivation for locking all the tables (possibly) used at once is to
      prevent dead locks.
      
      One problem with this approach is that, if the execution path the code
      really takes during runtime does not use a given table, and if the table is
      missing, the server would not execute the statement.
      This in particular has a major impact on triggers, since a missing table
      referenced by an update/delete trigger would prevent an insert trigger to run.
      
      Another problem is that stored routines might define SQL exception handlers
      to deal with missing tables, but the server implementation would never give
      user code a chance to execute this logic, since the routine is never
      executed when a missing table cause the pre-locking code to fail.
      
      With this fix, the internal implementation of the pre-locking code has been
      relaxed of some constraints, so that failure to open a table does not
      necessarily prevent execution of a stored routine.
      
      In particular, the pre-locking mechanism is now behaving as follows:
      
      1) the first step, to compute the transitive closure of all the tables
      possibly referenced by a statement, is unchanged.
      
      2) the next step, which is to open all the tables involved, only attempts
      to open the tables added by the pre-locking code, but silently fails without
      reporting any error or invoking any exception handler is the table is not
      present. This is achieved by trapping internal errors with
      Prelock_error_handler
      
      3) the locking step only locks tables that were successfully opened.
      
      4) when executing sub statements, the list of tables used by each statements
      is evaluated as before. The tables needed by the sub statement are expected
      to be already opened and locked. Statement referencing tables that were not
      opened in step 2) will fail to find the table in the open list, and only at
      this point will execution of the user code fail.
      
      5) when a runtime exception is raised at 4), the instruction continuation
      destination (the next instruction to execute in case of SQL continue
      handlers) is evaluated.
      This is achieved with sp_instr::exec_open_and_lock_tables()
      
      6) if a user exception handler is present in the stored routine, that
      handler is invoked as usual, so that ER_NO_SUCH_TABLE exceptions can be
      trapped by stored routines. If no handler exists, then the runtime execution
      will fail as expected.
      
      With all these changes, a side effect is that view security is impacted, in
      two different ways.
      
      First, a view defined as "select stored_function()", where the stored
      function references a table that may not exist, is considered valid.
      The rationale is that, because the stored function might trap exceptions
      during execution and still return a valid result, there is no way to decide
      when the view is created if a missing table really cause the view to be invalid.
      
      Secondly, testing for existence of tables is now done later during
      execution. View security, which consist of trapping errors and return a
      generic ER_VIEW_INVALID (to prevent disclosing information) was only
      implemented at very specific phases covering *opening* tables, but not
      covering the runtime execution. Because of this existing limitation,
      errors that were previously trapped and converted into ER_VIEW_INVALID are
      not trapped, causing table names to be reported to the user.
      This change is exposing an existing problem, which is independent and will
      be resolved separately.
      
      
      mysql-test/r/information_schema_db.result:
        Revised the pre-locking code implementation, aligned the tests.
      mysql-test/r/sp-error.result:
        Revised the pre-locking code implementation, aligned the tests.
      mysql-test/r/sp.result:
        Revised the pre-locking code implementation, aligned the tests.
      mysql-test/r/trigger.result:
        Revised the pre-locking code implementation, aligned the tests.
      mysql-test/r/view.result:
        Revised the pre-locking code implementation, aligned the tests.
      mysql-test/t/sp-error.test:
        Revised the pre-locking code implementation, aligned the tests.
      mysql-test/t/sp.test:
        Revised the pre-locking code implementation, aligned the tests.
      mysql-test/t/trigger.test:
        Revised the pre-locking code implementation, aligned the tests.
      sql/lock.cc:
        table->placeholder now checks for schema_table
      sql/mysqld.cc:
        my_message_sql(): invoke internal exception handlers
      sql/sp_head.cc:
        exec_open_and_lock_tables(): open and lock tables, or return the
        continuation destination of this instruction
      sql/sp_head.h:
        exec_open_and_lock_tables(): open and lock tables, or return the
        continuation destination of this instruction
      sql/sql_base.cc:
        Prelock_error_handler: delay open table errors until execution
      sql/sql_class.cc:
        THD: add internal error handler, as an exception mechanism.
      sql/sql_class.h:
        THD: add internal error handler, as an exception mechanism.
      sql/sql_update.cc:
        table->placeholder now checks for schema_table
      sql/table.cc:
        st_table_list::hide_view_error(): masked more errors for view security
      sql/table.h:
        table->placeholder now checks for schema_table, and unopened tables
      266a7fff
  34. 05 Mar, 2007 1 commit
    • unknown's avatar
      Fixed bug #26560. · 6da758c2
      unknown authored
      The flag alias_name_used was not set on for the outer references
      in subqueries. It resulted in replacement of any outer reference
      resolved against an alias for a full field name when the frm 
      representation of a view with a subquery was generated. 
      If the subquery and the outer query referenced the same table in
      their from lists this replacement effectively changed the meaning
      of the view and led to wrong results for selects from this view. 
      
      Modified several functions to ensure setting the right value of
      the alias_name_used flag for outer references resolved against
      aliases.
       
      
      
      mysql-test/r/view.result:
        Added a test case for bug #26560.
      mysql-test/t/view.test:
        Added a test case for bug #26560.
      sql/item.cc:
        Fixed bug #26560.
        Made the function resolve_ref_in_select_and_group analyze the return
        value of the last parameter with the type of the name resolution for
        the submitted reference. If the reference has been resolved against 
        an alias name from select list then its flag alias_name_used is set on.
        Now this value is used in Item_field::fix_outer_field to initialize the flag
        when the item_ref object is created for an outer reference.
        Added a parameter for the second Item_ref::Item_ref constructor to initialize
        properly the flag alias_name_used. The default value of the parameter is FALSE.
        If this flag is set on at the creation of an object by this constructor it
        will never be changed. Corrected appropriately the Item_ref::set_properties
        function.
        The function Item_ref::print now prints alias name for an outer reference
        if the flag alias_name_used is set on.
      sql/item.h:
        Fixed bug #26560.
        Added a parameter for the second Item_ref::Item_ref constructor to initialize
        properly the flag alias_name_used. The default value of the parameter is FALSE.
        A similar change has been applied to the first Item_direct_ref::Item_direct_ref
        constructor.
      sql/mysql_priv.h:
        Fixed bug #26560.
        Added an an enumeration type enum_resolution_type to return info on
        how the function find_item_in_list has resolved the submitted item.
        The type is used only for this function.
      sql/sql_base.cc:
        Fixed bug #26560.
        Made the last parameter of the function find_field_in_tables return
        more detailed information on how the submitted item has been resolved.
        Now it says whether the item has been resolved
          against an alias name,
          or as a field name without alias,
          or as a field name hidden by alias, 
          or was resolved ignoring alias.
      sql/sql_select.cc:
        Fixed bug #26560.
        Took into account the new type of the last parameter of the function
        find_item_in_list.
      6da758c2
  35. 03 Mar, 2007 1 commit
    • unknown's avatar
      Bug#25126: Wrongly resolved field leads to a crash. · 72773f4f
      unknown authored
      When the ORDER BY clause gets fixed it's allowed to search in the current
      item_list in order to find aliased fields and expressions. This is ok for a
      SELECT but wrong for an UPDATE statement. If the ORDER BY clause will
      contain a non-existing field which is mentioned in the UPDATE set list
      then the server will crash due to using of non-existing (0x0) field.
      
      When an Item_field is getting fixed it's allowed to search item list for
      aliased expressions and fields only for selects.
      
      
      sql/sql_base.cc:
        Bug#25126: Wrongly resolved field leads to a crash.
        When an Item_field is getting fixed it's allowed to search item list for
        aliased expressions and fields only for selects.
      sql/sql_select.cc:
        Bug#25126: Wrongly resolved field leads to a crash.
        When an Item_field is getting fixed it's allowed to search item list for
        aliased expressions and fields only for selects.
      mysql-test/r/update.result:
        Added a test case for bug#25126: Wrongly resolved field leads to a crash.
      mysql-test/t/update.test:
        Added a test case for bug#25126: Wrongly resolved field leads to a crash.
      72773f4f
  36. 02 Mar, 2007 1 commit
    • unknown's avatar
      sql_base.cc: · 19948e8a
      unknown authored
        Post fix for bug#25122.
      
      
      sql/sql_base.cc:
        Post fix for bug#25122.
      19948e8a