An error occurred fetching the project authors.
  1. 24 Jul, 2009 1 commit
    • Alexey Kopytov's avatar
      Bug #46075: Assertion failed: 0, file .\protocol.cc, line 416 · c76f98a5
      Alexey Kopytov authored
      In create_myisam_from_heap() mark all errors as fatal except 
      HA_ERR_RECORD_FILE_FULL for a HEAP table.
      
      Not doing so could lead to problems, e.g. in a case when a
      temporary MyISAM table gets overrun due to its MAX_ROWS limit
      while executing INSERT/REPLACE IGNORE ... SELECT. 
      The SELECT execution was aborted, but the error was 
      converted to a warning due to IGNORE clause, so neither 'ok' 
      nor 'error' packet could be sent back to the client. This 
      condition led to hanging client when using 5.0 server, or 
      assertion failure in 5.1.
      c76f98a5
  2. 04 May, 2009 1 commit
    • Martin Hansson's avatar
      Bug#44306: Assertion fail on duplicate key error in · 8fa68f57
      Martin Hansson authored
      'INSERT ... SELECT' statements
                  
      The code that produces result rows expected that a duplicate row
      error could not occur in INSERT ... SELECT statements with 
      unfulfilled WHERE conditions. This may happen, however, if the 
      SELECT list contains only aggregate functions.
      Fixed by checking if an error occured before trying to send EOF
      to the client.
      8fa68f57
  3. 21 Sep, 2007 1 commit
    • evgen@sunlight.local's avatar
      Bug#30384: Having SQL_BUFFER_RESULT option in the CREATE .. KEY(..) .. SELECT · bb5cdfb8
      evgen@sunlight.local authored
      led to creating corrupted index.
      
      While execution of the  CREATE .. SELECT SQL_BUFFER_RESULT statement the 
      engine->start_bulk_insert function was called twice. On the first call
      On the first call MyISAM disabled all non-unique indexes and on the second
      call it decides to not re-enable them because all indexes was disabled.
      Due to this no indexes was actually created during CREATE TABLE thus
      producing crashed table.
      
      Now the select_inset class has is_bulk_insert_mode flag which prevents
      calling the start_bulk_insert function twice.
      The flag is set in the select_create::prepare, select_insert::prepare2
      functions and the select_insert class constructor.
      The flag is reset in the select_insert::send_eof function.
      bb5cdfb8
  4. 31 Jul, 2007 1 commit
    • holyfoot/hf@mysql.com/hfmain.(none)'s avatar
      Bug #29717 INSERT INTO SELECT inserts values even if · f1ee2d06
      holyfoot/hf@mysql.com/hfmain.(none) authored
       SELECT statement itself returns empty.
      
      As a result of this bug 'SELECT AGGREGATE_FUNCTION(fld) ... GROUP BY'
      can return one row instead of an empty result set.
      
      When GROUP BY only has fields of constant tables
      (with a single row), the optimizer deletes the group_list.
      After that we lose the information about whether we had an
      GROUP BY statement. Though it's important
      as SELECT min(x) from empty_table; and
         SELECT min(x) from empty_table GROUP BY y; have to return
      different results - the first query should return one row,
      second - an empty result set.
      So here we add the 'group_optimized_away' flag to remember this case
      when GROUP BY exists in the query and is removed
      by the optimizer, and check this flag in end_send_group()
      f1ee2d06
  5. 23 Jun, 2007 1 commit
    • gshchepa/uchum@gleb.loc's avatar
      Fixed bug #29095. · fbbb30a6
      gshchepa/uchum@gleb.loc authored
      INSERT into table from SELECT from the same table
      with ORDER BY and LIMIT was inserting other data
      than sole SELECT ... ORDER BY ... LIMIT returns.
      
      One part of the patch for bug #9676 improperly pushed
      LIMIT to temporary table in the presence of the ORDER BY
      clause.
      That part has been removed.
      fbbb30a6
  6. 06 Jun, 2007 1 commit
    • jimw@rama.(none)'s avatar
      Bug #28842 Different 'duplicate key' error code between 5.0 and 5.1 · 3c93323d
      jimw@rama.(none) authored
        The patch for WL 1563 added a new duplicate key error message so that the
        key name could be provided instead of the key number. But the error code
        for the new message was used even though that did not need to change.
      
        This could cause unnecessary problems for applications that used the old
        ER_DUP_ENTRY error code to detect duplicate key errors.
      3c93323d
  7. 22 Mar, 2007 1 commit
    • gkodinov/kgeorge@magare.gmz's avatar
      Bug #26207: When making the key image to use · ef1bb48a
      gkodinov/kgeorge@magare.gmz authored
       in index search MySQL was not explicitly
       suppressing warnings. And if the context 
       happens to enable warnings (e.g. INSERT ..
       SELECT) the warnings resulting from converting 
       the data the key is compared to are 
       reported to the client.
       Fixed by suppressing warnings when converting
       the data to the same type as the key parts.
      ef1bb48a
  8. 26 Feb, 2007 1 commit
  9. 16 Feb, 2007 1 commit
    • evgen@moonbone.local's avatar
      Bug#16630: The update fields of the INSERT .. SELECT .. ON DUPLICATE KEY · 7916d9e9
      evgen@moonbone.local authored
      UPDATE contains wrong data if the SELECT employs a temporary table.
      
      If the UPDATE values of the INSERT .. SELECT .. ON DUPLICATE KEY UPDATE
      statement contains fields from the SELECT part and the select employs a
      temporary table then those fields will contain wrong values because they
      aren't corrected to get data from the temporary table.
      
      The solution is to add these fields to the selects all_fields list,
      to store pointers to those fields in the selects ref_pointer_array and
      to access them via Item_ref objects.
      
      The substitution for Item_ref objects is done in the new function called 
      Item_field::update_value_transformer(). It is called through the
      item->transform() mechanism at the end of the select_insert::prepare()
      function.
      7916d9e9
  10. 13 Feb, 2007 1 commit
  11. 09 Feb, 2007 1 commit
  12. 06 Feb, 2007 1 commit
    • evgen@moonbone.local's avatar
      Bug#19978: INSERT .. ON DUPLICATE erroneously reports some records were · 96836990
      evgen@moonbone.local authored
      updated.
      
      INSERT ... ON DUPLICATE KEY UPDATE reports that a record was updated when
      the duplicate key occurs even if the record wasn't actually changed
      because the update values are the same as those in the record.
      
      Now the compare_record() function is used to check whether the record was
      changed and the update of a record reported only if the record differs
      from the original one.
      96836990
  13. 22 Jan, 2007 1 commit
  14. 13 Nov, 2006 1 commit
  15. 12 Sep, 2006 1 commit
    • timour/timka@lamia.home's avatar
      Fix for BUG#21774: Column count doesn't match value count at row x · 38a450b4
      timour/timka@lamia.home authored
      The cause of the bug was an incomplete fix for bug 18080.
      The problem was that setup_tables() unconditionally reset the
      name resolution context to its 'tables' argument, which pointed
      to the first table of an SQL statement.
      
      The bug fix limits resetting of the name resolution context in
      setup_tables() only in the cases when the context was not set
      by earlier parser/optimizer phases.
      38a450b4
  16. 19 Jul, 2006 1 commit
  17. 19 Jun, 2006 2 commits
    • gkodinov@mysql.com's avatar
      Bug #18080: INSERT ... SELECT ... JOIN results in ambiguous field list error · 5508df25
      gkodinov@mysql.com authored
      There was an incomplete reset of the name resolution context, that caused 
      INSERT ... SELECT ... JOIN statements to resolve not by joint row type calculated
      for the join.
      Removed the redundant re-initialization of the context, because 
      mysql_insert_select_prepare() now correctly saves/restores the context.
      5508df25
    • gkodinov@mysql.com's avatar
      * Bug #9676: INSERT INTO x SELECT .. FROM x LIMIT 1; slows down with big · c5ed7a87
      gkodinov@mysql.com authored
                    tables
      Currently in INSERT ... SELECT ... LIMIT ... the compiler uses a 
      temporary table to store the results of SELECT ... LIMIT .. and then
      uses that table as a source for INSERT. The problem is that in some cases
      it actually skips the LIMIT clause in doing that and materializes the 
      whole SELECT result set regardless of the LIMIT.
      This fix is limiting the process of filling up the temp table with only 
      that much rows that will be actually used by propagating the LIMIT value.
      c5ed7a87
  18. 27 Oct, 2005 1 commit
  19. 25 Oct, 2005 1 commit
  20. 15 Sep, 2005 1 commit
  21. 09 Sep, 2005 1 commit
  22. 12 Aug, 2005 1 commit
    • timour@mysql.com's avatar
      Implementation of WL#2486 - · a247282a
      timour@mysql.com authored
      "Process NATURAL and USING joins according to SQL:2003".
      
      * Some of the main problems fixed by the patch:
        - in "select *" queries the * expanded correctly according to
          ANSI for arbitrary natural/using joins
        - natural/using joins are correctly transformed into JOIN ... ON
          for any number/nesting of the joins.
        - column references are correctly resolved against natural joins
          of any nesting and combined with arbitrary other joins.
      
      * This patch also contains a fix for name resolution of items
        inside the ON condition of JOIN ... ON - in this case items must
        be resolved only against the JOIN operands. To support such
        'local' name resolution, the patch introduces a stack of
        name resolution contexts used at parse time.
      
      NOTICE:
      - This patch is not complete in the sense that
        - there are 2 test cases that still do not pass -
          one in join.test, one in select.test. Both are marked
          with a comment "TODO: WL#2486".
        - it does not include a new test specific for the task
      a247282a
  23. 28 Jul, 2005 1 commit
  24. 27 Jun, 2005 1 commit
    • monty@mishka.local's avatar
      Better bug fix for: · 83f90e06
      monty@mishka.local authored
      #9728  'Decreased functionality in "on duplicate key update
      #8147  'a column proclaimed ambigous in INSERT ... SELECT .. ON DUPLICATE'
      
      This ensures fields are uniquely qualified and also that one can't update other tables in the ON DUPLICATE KEY UPDATE part
      83f90e06
  25. 22 Jun, 2005 1 commit
  26. 21 Jun, 2005 1 commit
  27. 31 Mar, 2005 1 commit
  28. 16 Mar, 2005 1 commit
    • dlenev@brandersnatch.localdomain's avatar
      WL#874 "Extended LOAD DATA". · f1691140
      dlenev@brandersnatch.localdomain authored
      Now one can use user variables as target for data loaded from file
      (besides table's columns). Also LOAD DATA got new SET-clause in which
      one can specify values for table columns as expressions.
      
      For example the following is possible:
      LOAD DATA INFILE 'words.dat' INTO TABLE t1 (a, @b) SET c = @b + 1;
      
      This patch also implements new way of replicating LOAD DATA.
      Now we do it similarly to other queries.
      We store LOAD DATA query in new Execute_load_query event
      (which is last in the sequence of events representing LOAD DATA).
      When we are executing this event we simply rewrite part of query which
      holds name of file (we use name of temporary file) and then execute it
      as usual query. In the beggining of this sequence we use Begin_load_query
      event which is almost identical to Append_file event
      f1691140
  29. 19 Jan, 2005 3 commits
    • ingo@mysql.com's avatar
      BUG#6034 - Error code 124: Wrong medium type. · ea8882be
      ingo@mysql.com authored
      Version for 5.0. Committed for merge.
      If the result table is one of the select tables in INSERT SELECT,
      we must not disable the result tables indexes before selecting.
      Now the preparation is split into two prepare methods.
      The first detects the situation and defers some preparations
      until the second phase.
      ea8882be
    • ingo@mysql.com's avatar
      BUG#6034 - Error code 124: Wrong medium type. · fd0fdcda
      ingo@mysql.com authored
      Version for 4.1. Committed for merge.
      If the result table is one of the select tables in INSERT SELECT,
      we must not disable the result tables indexes before selecting.
      mysql_execute_command() detects the match for other reasons and
      adds the flag OPTION_BUFFER_RESULT to the 'select_options'. 
      In this case the result is put into a temporary table first. 
      Hence, we can defer the preparation of the insert
      table until the result is to be used.
      fd0fdcda
    • ingo@mysql.com's avatar
      BUG#6034 - Error code 124: Wrong medium type. · 9a914a00
      ingo@mysql.com authored
      Version for 4.0. Committed for merge.
      If the result table is one of the select tables in INSERT SELECT,
      we must not disable the result tables indexes before selecting.
      mysql_execute_command() detects the match for other reasons and
      adds the flag OPTION_BUFFER_RESULT to the 'select_options'. 
      In this case the result is put into a temporary table first. 
      Hence, we can defer the preparation of the insert
      table until the result is to be used.
      9a914a00
  30. 04 Jan, 2005 1 commit
    • monty@mysql.com's avatar
      After merge fixes · 7cf8285b
      monty@mysql.com authored
      Add support for warnings for prepare of prepared statements
      Fixed test to work with --ps-protocol
      Fixed some test results
      7cf8285b
  31. 02 Dec, 2004 1 commit
    • jimw@mysql.com's avatar
      Prevent adding 'CREATE TABLE .. SELECT' query to the binary log when the · 13649d90
      jimw@mysql.com authored
      insertion of new records partially failed. It would get logged because of the
      logic to log a partially-failed 'INSERT ... SELECT' (which can't be rolled back
      in non-transactional tables), but 'CREATE TABLE ... SELECT' is always rolled
      back on failure, even for non-transactional tables. (Bug #6682)
      (Original fix reimplemented after review by Serg and Guilhem.)
      13649d90
  32. 26 Oct, 2004 1 commit
    • monty@mysql.com's avatar
      A lot of fixes for prepared statements (PS): · 6fbc869d
      monty@mysql.com authored
      New mysqltest that can run mysqltest with PS
      Added support for ZEROFILL in PS
      Fixed crash when one called mysql_stmt_store_result() without a preceding mysql_stmt_bind_result()
      Updated test cases to support --ps-protocol
      (Some tests are still run using old protocol)
      Fixed crash in PS when using SELECT * FROM t1 NATURAL JOIN t2...
      Fixed crash in PS when using sub queries
      Create table didn't signal when table was created. This could cause a "DROP TABLE created_table" in another thread to wait "forever"
      Fixed wrong permissions check in PS and multi-table updates (one could get permission denied for legal quries)
      Fix for PS and SELECT ... PROCEDURE
      Reset all warnings when executing a new PS query
      group_concat(...ORDER BY) didn't work with PS
      Fixed problem with test suite when not using innodb
      6fbc869d
  33. 06 Feb, 2004 1 commit
  34. 16 Dec, 2003 1 commit
  35. 10 Dec, 2003 1 commit
  36. 08 Oct, 2003 1 commit
  37. 18 Aug, 2003 1 commit
    • monty@mashka.mysql.fi's avatar
      After merge fixes · 4f751216
      monty@mashka.mysql.fi authored
      Use server character set if --default-character-set is not used
      Added convert_string() for more efficient alloc+character-set convert of strings
      4f751216