An error occurred fetching the project authors.
  1. 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
  2. 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
  3. 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
  4. 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
  5. 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
  6. 16 Aug, 2007 2 commits
  7. 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
  8. 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
  9. 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
  10. 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
  11. 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
  12. 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
  13. 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
  14. 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
  15. 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
  16. 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
  17. 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
  18. 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
  19. 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
  20. 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
  21. 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
  22. 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
  23. 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
  24. 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
  25. 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
  26. 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
  27. 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
  28. 01 Mar, 2007 1 commit
    • unknown's avatar
      Bug#25122: Views based on a self-joined table aren't insertable. · 1437a9c5
      unknown authored
      When INSERT is done over a view the table being inserted into is 
      checked to be unique among all views tables. But if the view contains
      self-joined table an error will be thrown even if all tables are used under
      different aliases.
      
      The unique_table() function now also checks tables' aliases when needed.
      
      
      sql/mysql_priv.h:
        Bug#25122:  Views based on a self-joined table aren't insertable.
        Updated prototype of the unique_table() function.
      sql/sql_base.cc:
        Bug#25122:  Views based on a self-joined table aren't insertable.
        Now the unique_table() function checks tables' aliases when needed.
      sql/sql_delete.cc:
        Bug#25122:  Views based on a self-joined table aren't insertable.
        Updated calls to the unique_table() function.
      sql/sql_insert.cc:
        Bug#25122:  Views based on a self-joined table aren't insertable.
        Updated calls to the unique_table() function.
      sql/sql_load.cc:
        Bug#25122:  Views based on a self-joined table aren't insertable.
        Updated calls to the unique_table() function.
      sql/sql_parse.cc:
        Bug#25122:  Views based on a self-joined table aren't insertable.
        Updated calls to the unique_table() function.
      sql/sql_update.cc:
        Bug#25122:  Views based on a self-joined table aren't insertable.
        Updated calls to the unique_table() function.
      1437a9c5
  29. 28 Feb, 2007 1 commit
  30. 22 Feb, 2007 1 commit
    • unknown's avatar
      Fixed compiler warnings (for linux and win32 and win64) · 50bd97a9
      unknown authored
      Fixed a couple of usage of not initialized warnings (unlikely cases)
      
      
      client/mysqldump.c:
        Fixed compiler warnings from 'max' build
      client/mysqltest.c:
        Removed compiler warnings
      cmd-line-utils/readline/xmalloc.c:
        Fixed compiler warnings from 'max' build
      extra/comp_err.c:
        Fixed compiler warnings from 'max' build
      extra/yassl/include/openssl/ssl.h:
        Changed prototype for SSL_set_fd() to fix compiler warnings (and possible errors) on windows 64 bit
      extra/yassl/include/socket_wrapper.hpp:
        Moved socket_t to ssl.h, to be able to removed compiler warnings on windows 64 bit
      extra/yassl/src/ssl.cpp:
        Changed prototype for SSL_set_fd() to fix compiler warnings (and possible errors) on windows 64 bit
      extra/yassl/taocrypt/src/integer.cpp:
        Fixed compiler warnings
      include/my_global.h:
        Added my_offsetof() macro from 5.1 to get rid of compiler warnings
      innobase/include/ut0byte.ic:
        Fixed compiler warnings on win64
      innobase/include/ut0ut.ic:
        Fixed compiler warnings on win64
      libmysql/libmysql.def:
        Fixed compiler warnings on win64
      myisam/mi_packrec.c:
        Fixed compiler warnings on win64
      myisam/myisamchk.c:
        Fixed compiler warnings from 'max' build
      mysys/base64.c:
        Fixed compiler warnings on win64
      mysys/mf_keycache.c:
        Fixed compiler warnings from 'max' build
      mysys/my_getopt.c:
        Fixed compiler warnings from 'max' build
      mysys/my_init.c:
        Fixed compiler warnings from 'max' build
      mysys/my_thr_init.c:
        Fixed compiler warnings
      mysys/ptr_cmp.c:
        Fixed compiler warnings from 'max' build
      ndb/include/kernel/signaldata/DictTabInfo.hpp:
        Fixed compiler warnings
      server-tools/instance-manager/mysql_connection.cc:
        Fixed compiler warnings
      server-tools/instance-manager/mysqlmanager.cc:
        Fixed compiler warnings
      sql/filesort.cc:
        Initalize variable that was used unitialized in error conditions
      sql/ha_berkeley.cc:
        Moved get_auto_primary_key() here as int5store() gives (wrong) compiler warnings in win64
      sql/ha_berkeley.h:
        Moved get_auto_primary_key() to ha_berkeley.cc
      sql/ha_innodb.cc:
        Fixed compiler warnings
      sql/item.cc:
        Fixed compiler warnings from 'max' build
      sql/item_timefunc.cc:
        Fixed compiler warnings
      sql/mysqld.cc:
        Fixed compiler warnings
      sql/sql_acl.cc:
        Fixed compiler warnings from 'max' build
      sql/sql_base.cc:
        Fixed compiler warnings from 'max' build
      sql/sql_insert.cc:
        Initialize variable that may be used unitialized on error conditions (not fatal)
      sql/sql_prepare.cc:
        Fixed compiler warnings from 'max' build
      sql/sql_select.cc:
        Fixed compiler warnings
      sql/sql_show.cc:
        Fixed compiler warnings
      sql/udf_example.def:
        Fixed compiler warnings on win64
      sql/unireg.cc:
        Initialize variable that may be used unitialized on error conditions
      strings/ctype-ucs2.c:
        Fixed compiler warnings
      strings/ctype-utf8.c:
        Fixed compiler warnings
      strings/decimal.c:
        Fixed compiler warnings
      support-files/compiler_warnings.supp:
        Ignore warnings from sql_yacc.cc that are hard to remove
        Ignore some not important warnings from windows 64 bit build
      tools/mysqlmanager.c:
        Fixed compiler warnings
      50bd97a9
  31. 19 Feb, 2007 1 commit
    • unknown's avatar
      Bug #25831: Deficiencies in INSERT ... SELECT ... field name resolving. · a97fd193
      unknown authored
       Several problems fixed: 
        1. There was a "catch-all" context initialization in setup_tables()
          that was causing the table that we insert into to be visible in the 
          SELECT part of an INSERT .. SELECT .. statement with no tables in
          its FROM clause. This was making sure all the under-initialized
          contexts in various parts of the code are not left uninitialized.
          Fixed by removing the "catch-all" statement and initializing the 
          context in the parser.
        2. Incomplete name resolution context when resolving the right-hand
          values in the ON DUPLICATE KEY UPDATE ... part of an INSERT ... SELECT ...
          caused columns from NATURAL JOIN/JOIN USING table references in the
          FROM clause of the select to be unavailable.
          Fixed by establishing a proper name resolution context.
        3. When setting up the special name resolution context for problem 2
          there was no check for cases where an aggregate function without a
          GROUP BY effectively takes the column from the SELECT part of an 
          INSERT ... SELECT unavailable for ON DUPLICATE KEY UPDATE.
          Fixed by checking for that condition when setting up the name 
          resolution context.
      
      
      mysql-test/r/insert_update.result:
        Bug #25831: Deficiencies in INSERT ... SELECT ... field name resolving.
         - test case
      mysql-test/t/insert_update.test:
        Bug #25831: Deficiencies in INSERT ... SELECT ... field name resolving.
         - test case
      sql/item.h:
        Bug #25831: Deficiencies in INSERT ... SELECT ... field name resolving.
         - save_next_local is not referenced any more outside class methods
      sql/sql_base.cc:
        Bug #25831: Deficiencies in INSERT ... SELECT ... field name resolving.
         - removed a "catch-all" code to cater for correct context initialization
      sql/sql_help.cc:
        Bug #25831: Deficiencies in INSERT ... SELECT ... field name resolving.
         - fixed the name resolution context initialization
      sql/sql_insert.cc:
        Bug #25831: Deficiencies in INSERT ... SELECT ... field name resolving.
         - Fixed the context of resolving the values in INSERT SELECT ON UPDATE
      sql/sql_prepare.cc:
        Bug #25831: Deficiencies in INSERT ... SELECT ... field name resolving.
         - Correct context for name resolution of prepared INSERT .. SELECT
      sql/sql_union.cc:
        Bug #25831: Deficiencies in INSERT ... SELECT ... field name resolving.
         - fixed the name resolution context initialization
      sql/sql_yacc.yy:
        Bug #25831: Deficiencies in INSERT ... SELECT ... field name resolving.
         - Set the context here instead of setup_tables()
      a97fd193
  32. 31 Jan, 2007 1 commit
    • unknown's avatar
      BUG#25575: ERROR 1052 (Column in from clause is ambiguous) with sub-join · fbc16a85
      unknown authored
       Two problems here:
      
       Problem 1:
      
       While constructing the join columns list the optimizer does as follows:
        1. Sets the join_using_fields/natural_join members of the right JOIN 
         operand.
        2. Makes a "table reference" (TABLE_LIST) to parent the two tables.
        3. Assigns the join_using_fields/is_natural_join of the wrapper table
         using join_using_fields/natural_join of the rightmost table
        4. Sets join_using_fields to NULL for the right JOIN operand.
        5. Passes the parent table up to the same procedure on the upper 
         level.
      
       Step 1 overrides the the join_using_fields that are set for a nested 
       join wrapping table in step 4.
       Fixed by making a designated variable SELECT_LEX::prev_join_using to 
       pass the data from step 1 to step 4 without destroying the wrapping 
       table data.
      
       Problem 2:
      
       The optimizer checks for ambiguous columns while transforming 
       NATURAL JOIN/JOIN USING to JOIN ON. While doing that there was no
       distinction between columns that are used in the generated join
       condition (where ambiguity can be checked) and the other columns
       (where ambiguity can be checked only when resolving references
       coming from outside the JOIN construct itself).
       Fixed by allowing the non-USING columns to be present in multiple 
       copies in both sides of the join and moving the ambiguity check 
       to the place where unqualified references to the join columns are
       resolved (find_field_in_natural_join()).
      
      
      mysql-test/r/join_nested.result:
        BUG#25575: ERROR 1052 (Column in from clause is ambiguous) with sub-join
         - test case
      mysql-test/t/join_nested.test:
        BUG#25575: ERROR 1052 (Column in from clause is ambiguous) with sub-join
         - test case
      sql/mysql_priv.h:
        BUG#25575: ERROR 1052 (Column in from clause is ambiguous) with sub-join
         - use SELECT_LEX to store the ref to JOIN USING list needed by the 
           parser
      sql/sql_base.cc:
        BUG#25575: ERROR 1052 (Column in from clause is ambiguous) with sub-join
         - proper check for duplicate cols
         - more detailed debug output
      sql/sql_lex.h:
        BUG#25575: ERROR 1052 (Column in from clause is ambiguous) with sub-join
         - use SELECT_LEX to store the ref to JOIN USING list needed by the 
           parser
      sql/sql_parse.cc:
        BUG#25575: ERROR 1052 (Column in from clause is ambiguous) with sub-join
         - proper check for duplicate cols in JOIN USING
      sql/sql_yacc.yy:
        BUG#25575: ERROR 1052 (Column in from clause is ambiguous) with sub-join
         - use SELECT_LEX to store the ref to JOIN USING list needed by the 
           parser
      sql/table.cc:
        BUG#25575: ERROR 1052 (Column in from clause is ambiguous) with sub-join
         - return null if no table ref (as in nested join columns).
      fbc16a85
  33. 11 Jan, 2007 2 commits
    • unknown's avatar
      Bug#23417: Too strict checks against GROUP BY in the ONLY_FULL_GROUP_BY mode. · 4d143a6f
      unknown authored
      Currently in the ONLY_FULL_GROUP_BY mode no hidden fields are allowed in the
      select list. To ensure this each expression in the select list is checked
      to be a constant, an aggregate function or to occur in the GROUP BY list.
      The last two requirements are wrong and doesn't allow valid expressions like
      "MAX(b) - MIN(b)" or "a + 1" in a query with grouping by a.
      
      The correct check implemented by the patch will ensure that:
      any field reference in the [sub]expressions of the select list 
        is under an aggregate function or
        is mentioned as member of the group list or
        is an outer reference or
        is part of the select list element that coincide with a grouping element.
      
      The Item_field objects now can contain the position of the select list
      expression which they belong to. The position is saved during the
      field's Item_field::fix_fields() call.
      
      The non_agg_fields list for non-aggregated fields is added to the SELECT_LEX
      class. The SELECT_LEX::cur_pos_in_select_list now contains the position in the
      select list of the expression being currently fixed.
      
      
      sql/item.cc:
        Bug#23417: Too strict checks against GROUP BY in the ONLY_FULL_GROUP_BY mode.
        The Item_field objects now contain the position of the select list
        expression which they belong to. The position is saved at the field's
        Item_field::fix_fields() call.
      sql/item.h:
        Bug#23417: Too strict checks against GROUP BY in the ONLY_FULL_GROUP_BY mode.
        The Item_field objects now can store the position in the select list of the
        expression to which they are belongs to.
      sql/mysql_priv.h:
        Bug#23417: Too strict checks against GROUP BY in the ONLY_FULL_GROUP_BY mode.
        Added the UNDEF_POS constant.
      sql/sql_base.cc:
        Bug#23417: Too strict checks against GROUP BY in the ONLY_FULL_GROUP_BY mode.
        Now the setup_fields() function maintains the cur_pos_in_select_list variable.
      sql/sql_lex.cc:
        Bug#23417: Too strict checks against GROUP BY in the ONLY_FULL_GROUP_BY mode.
        Set the cur_pos_in_select_list variable and the non_agg_fields list to their initial state.
      sql/sql_lex.h:
        Bug#23417: Too strict checks against GROUP BY in the ONLY_FULL_GROUP_BY mode.
        The non_agg_fields list for non-aggregated fields is added to the SELECT_LEX
        class. The SELECT_LEX::cur_pos_in_select_list now stores the position in the
        select list of the expression being currently fixed.
      sql/sql_select.cc:
        Bug#23417: Too strict checks against GROUP BY in the ONLY_FULL_GROUP_BY mode.
        Each select now keeps the list of fields that aren't
        used under any aggregate function. If an expression from the select list
        isn't found in the GROUP BY list the setup_group() function additionally
        checks whether non-aggregated fields occur in that expression.
        If there at least one such field and it isn't found in the GROUP BY list
        then an error is thrown.
      sql/sql_union.cc:
        Bug#23417: Too strict checks against GROUP BY in the ONLY_FULL_GROUP_BY mode.
        Clean up of the non_agg_fields list.
      mysql-test/r/group_by.result:
        Added a test case for the bug#23417: Too strict checks against GROUP BY in the ONLY_FULL_GROUP_BY mode.
      mysql-test/t/group_by.test:
        Added a test case for the bug#23417: Too strict checks against GROUP BY in the ONLY_FULL_GROUP_BY mode.
      4d143a6f
    • unknown's avatar
      BUG#25106: A USING clause in combination with a VIEW results in column · 6c41a043
      unknown authored
                 aliases ignored
      When a column reference to a column in JOIN USING is resolved and a new 
      Item is created for this column the user defined name was lost.
      This fix preserves the alias by setting the name of the new Item to the
      original alias.
      
      
      mysql-test/r/join.result:
        BUG#25106: A USING clause in combination with a VIEW results in column
                   aliases ignored
         - test case
      mysql-test/t/join.test:
        BUG#25106: A USING clause in combination with a VIEW results in column
                   aliases ignored
         - test case
      sql/sql_base.cc:
        BUG#25106: A USING clause in combination with a VIEW results in column
                   aliases ignored
         - take the alias of the Item to be replaced and set it into the newly
           allocated Item.
      6c41a043
  34. 10 Jan, 2007 2 commits
    • unknown's avatar
      after merge fix · 53c9b0d0
      unknown authored
      53c9b0d0
    • unknown's avatar
      Fix for bug#20867 InnoDB Bug - create temporary table+crash => mysqld needs to clean up · ac71a8fa
      unknown authored
      2nd version
      During tmp tables cleanup we get the handler for temporary table
      and delete table using handler method.
      
      
      sql/mysql_priv.h:
        added function prototype
      sql/mysqld.cc:
        added call of mysql_rm_tmp_tables() function
      sql/sql_base.cc:
        mysql_rm_tmp_tables()
        -removed from table_cache_init
        -During tmp tables cleanup we get the handler for temporary table
         and delete table using handler method. 
         it allows to remove orphan records from data dictionary(InnoDB)
      ac71a8fa