1. 22 Jul, 2008 1 commit
  2. 21 Jul, 2008 1 commit
  3. 24 Jul, 2008 1 commit
  4. 21 Jul, 2008 1 commit
  5. 19 Jul, 2008 2 commits
  6. 18 Jul, 2008 2 commits
  7. 17 Jul, 2008 2 commits
  8. 16 Jul, 2008 5 commits
  9. 15 Jul, 2008 3 commits
    • Sergey Petrunia's avatar
      Merge · 7315a700
      Sergey Petrunia authored
      7315a700
    • Kristofer Pettersson's avatar
      auto merge · f81c2f07
      Kristofer Pettersson authored
      f81c2f07
    • Sergey Petrunia's avatar
      BUG#35478: sort_union() returns bad data when sort_buffer_size is hit · 62513bb1
      Sergey Petrunia authored
      - In QUICK_INDEX_MERGE_SELECT::read_keys_and_merge: when we got table->sort from Unique,
        tell init_read_record() not to use rr_from_cache() because a) rowids are already sorted
        and b) it might be that the the data is used by filesort(), which will need record rowids
        (which rr_from_cache() cannot provide).
      - Fully de-initialize the table->sort read in QUICK_INDEX_MERGE_SELECT::get_next(). This fixes BUG#35477.
      (bk trigger: file as fix for BUG#35478).
      
      sql/filesort.cc:
        BUG#35478: sort_union() returns bad data when sort_buffer_size is hit
        - make find_all_keys() use quick->get_next() instead of init_read_record(r)/r.read_record() calls
        - added dbug printout
      sql/mysql_priv.h:
        BUG#35478: sort_union() returns bad data when sort_buffer_size is hit
        - Added parameter to init_read_record
      sql/opt_range.cc:
        BUG#35478: sort_union() returns bad data when sort_buffer_size is hit
        - In QUICK_INDEX_MERGE_SELECT::read_keys_and_merge: when we got table->sort from Unique,
          tell init_read_record() not to use rr_from_cache() because a) rowids are already sorted
          and b) it might be that the the data is used by filesort(), which will need record rowids
          (which rr_from_cache() cannot provide).
        - Fully de-initialize the table->sort read in QUICK_INDEX_MERGE_SELECT::get_next().
      sql/records.cc:
        BUG#35478: sort_union() returns bad data when sort_buffer_size is hit
        - Added disable_rr_cache parameter to init_read_record
        - Added comment
      sql/sql_acl.cc:
        BUG#35478: sort_union() returns bad data when sort_buffer_size is hit
        - Added parameter to init_read_record
      sql/sql_delete.cc:
        BUG#35478: sort_union() returns bad data when sort_buffer_size is hit
        - Added parameter to init_read_record
      sql/sql_help.cc:
        BUG#35478: sort_union() returns bad data when sort_buffer_size is hit
        - Added parameter to init_read_record
      sql/sql_select.cc:
        BUG#35478: sort_union() returns bad data when sort_buffer_size is hit
        - Added parameter to init_read_record
      sql/sql_table.cc:
        BUG#35478: sort_union() returns bad data when sort_buffer_size is hit
        - Added parameter to init_read_record
      sql/sql_udf.cc:
        BUG#35478: sort_union() returns bad data when sort_buffer_size is hit
        - Added parameter to init_read_record
      sql/sql_update.cc:
        BUG#35478: sort_union() returns bad data when sort_buffer_size is hit
        - Added parameter to init_read_record
      62513bb1
  10. 14 Jul, 2008 3 commits
    • Marc Alff's avatar
      Merge · 5f9f35e2
      Marc Alff authored
      5f9f35e2
    • Marc Alff's avatar
      Bug#35577 (CREATE PROCEDURE causes either crash or syntax error depending on · e73e7bb9
      Marc Alff authored
      build)
      
      The crash was caused by freeing the internal parser stack during the parser
      execution.
      This occured only for complex stored procedures, after reallocating the parser
      stack using my_yyoverflow(), with the following C call stack:
      - MYSQLparse()
      - any rule calling sp_head::restore_lex()
      - lex_end()
      - x_free(lex->yacc_yyss), xfree(lex->yacc_yyvs)
      
      The root cause is the implementation of stored procedures, which breaks the
      assumption from 4.1 that there is only one LEX structure per parser call.
      
      The solution is to separate the LEX structure into:
      - attributes that represent a statement (the current LEX structure),
      - attributes that relate to the syntax parser itself (Yacc_state),
      so that parsing multiple statements in stored programs can create multiple
      LEX structures while not changing the unique Yacc_state.
      
      Now, Yacc_state and the existing Lex_input_stream are aggregated into
      Parser_state, a structure that represent the complete state of the (Lexical +
      Syntax) parser.
      
      
      mysql-test/r/parser_stack.result:
        Bug#35577 (CREATE PROCEDURE causes either crash or syntax error depending on
        build)
      mysql-test/t/parser_stack.test:
        Bug#35577 (CREATE PROCEDURE causes either crash or syntax error depending on
        build)
      sql/sp.cc:
        Bug#35577 (CREATE PROCEDURE causes either crash or syntax error depending on
        build)
      sql/sp_head.cc:
        Bug#35577 (CREATE PROCEDURE causes either crash or syntax error depending on
        build)
      sql/sql_class.cc:
        Bug#35577 (CREATE PROCEDURE causes either crash or syntax error depending on
        build)
      sql/sql_class.h:
        Bug#35577 (CREATE PROCEDURE causes either crash or syntax error depending on
        build)
      sql/sql_lex.cc:
        Bug#35577 (CREATE PROCEDURE causes either crash or syntax error depending on
        build)
      sql/sql_lex.h:
        Bug#35577 (CREATE PROCEDURE causes either crash or syntax error depending on
        build)
      sql/sql_parse.cc:
        Bug#35577 (CREATE PROCEDURE causes either crash or syntax error depending on
        build)
      sql/sql_prepare.cc:
        Bug#35577 (CREATE PROCEDURE causes either crash or syntax error depending on
        build)
      sql/sql_trigger.cc:
        Bug#35577 (CREATE PROCEDURE causes either crash or syntax error depending on
        build)
      sql/sql_view.cc:
        Bug#35577 (CREATE PROCEDURE causes either crash or syntax error depending on
        build)
      sql/sql_yacc.yy:
        Bug#35577 (CREATE PROCEDURE causes either crash or syntax error depending on
        build)
      e73e7bb9
    • Joerg Bruehe's avatar
      Merge main 5.0 into 5.0-build · d156cc64
      Joerg Bruehe authored
      d156cc64
  11. 10 Jul, 2008 4 commits
    • Gleb Shchepa's avatar
      warning elimination · d5077086
      Gleb Shchepa authored
      d5077086
    • Gleb Shchepa's avatar
      warning elimination · 547ca139
      Gleb Shchepa authored
      547ca139
    • Tatiana A. Nurnberg's avatar
      auto-merge · 0617cf0f
      Tatiana A. Nurnberg authored
      0617cf0f
    • Tatiana A. Nurnberg's avatar
      Bug#35848: UUID() returns UUIDs with the wrong time · 0833d668
      Tatiana A. Nurnberg authored
      offset for time part in UUIDs was 1/1000 of what it
      should be. In other words, offset was off.
      
      Also handle the case where we count into the future
      when several UUIDs are generated in one "tick", and
      then the next call is late enough for us to unwind
      some but not all of those borrowed ticks.
      
      Lastly, handle the case where we keep borrowing and
      borrowing until the tick-counter overflows by also
      changing into a new "numberspace" by creating a new
      random suffix.
      
      
      mysql-test/r/func_misc.result:
        Show that time-part of UUIDs is correct now.
      mysql-test/t/func_misc.test:
        Show that time-part of UUIDs is correct now
        by replicating the C-code's resultin SQL.
        Results also decode to expect date-data on
        command-line (external validation).
        
        No test for unwinding of borrowed ticks as
        this a) is a race and b) depends on what timer
        we get.
      sql/item_strfunc.cc:
        correct offset for date/time-part of UUID.
        also make sure that when we counted into
        the future earlier (several UUIDs generated
        in same tick), we only give back as many
        "borrowed" ticks as we can without duplicating
        past timestamps. If our tick-counter overflows
        before we can give back, or if the system-clock
        is set back (by user or Daylight Saving Time),
        we create a new random suffix to avoid
        collisions and clear the tick-counter.
      0833d668
  12. 09 Jul, 2008 6 commits
  13. 08 Jul, 2008 2 commits
  14. 07 Jul, 2008 3 commits
    • Marc Alff's avatar
      Merge · a8a986bd
      Marc Alff authored
      a8a986bd
    • Marc Alff's avatar
      Bug#26030 (Parsing fails for stored routine w/multi-statement execution · c7724872
      Marc Alff authored
      enabled)
      
      Before this fix, the lexer and parser would treat the ';' character as a
      different token (either ';' or END_OF_INPUT), based on convoluted logic,
      which failed in simple cases where a stored procedure is implemented as a
      single statement, and used in a multi query.
      
      With this fix:
      - the character ';' is always parsed as a ';' token in the lexer,
      - parsing multi queries is implemented in the parser, in the 'query:' rules,
      - the value of thd->client_capabilities, which is the capabilities
        negotiated between the client and the server during bootstrap,
        is immutable and not arbitrarily modified during parsing (which was the
        root cause of the bug)
      
      c7724872
    • Mats Kindahl's avatar
      Bug #37150 Risk for crash in User_var_log_event::exec_event() · 914cae3a
      Mats Kindahl authored
      On certain kinds of errors (e.g., out of stack), a call to Item_func_
      set_user_var::fix_fields() might fail.  Since the return value of this
      call was not checked inside User_var_log_event::exec_event(), continuing
      execution after this will cause a crash inside Item_func_set_user_var::
      update_hash().
      
      The bug is fixed by aborting execution of the event with an error if
      fix_fields() fails, since it is not possible to continue execution anyway.
      
      
      sql/log_event.cc:
        Aborting execution of event if fix_fields() fails since execution
        of update_hash() might cause a crash.
      914cae3a
  15. 05 Jul, 2008 1 commit
  16. 04 Jul, 2008 2 commits
  17. 02 Jul, 2008 1 commit