1. 25 Aug, 2008 1 commit
    • Joerg Bruehe's avatar
      Bug#37098 Get rid of "Installed (but unpackaged)" files in the RPM build · 8a5406a3
      Joerg Bruehe authored
      Mostly, this affected files (programs, scripts, and manual pages)
      which got built during a RPM build but were not listed in the
      appropriate "%files" section of the "spec" file.
      This is fixed now, they are added.
      
      To make this consistent, this patch also makes the build of "innochecksum"
      (and its inclusion in a tar.gz or other package) depend on whether InnoDB
      is configured in the build.
      
      Also, some tools to create Windows packages are irrelevant in any binary
      Unix package (not the sources !), and so they are deleted before packaging.
      
      configure.in:
        To prevent "innochecksum" from getting built even if InnoDB is not configured
        (and then being included in such packages),
        we need an "automake condition" that evaluates whether we have InnoDB.
      extra/Makefile.am:
        Evaluate the new automake condition about having InnoDB,
        and make the build of "innochecksum" depend on it.
      man/Makefile.am:
        Cleanup: There are manual files which we do not need,
        like those about tools for Windows builds / packaging
        (irrelevant in any Unix binary package)
        and about NDB tools which do not get built.
      scripts/make_binary_distribution.sh:
        In any Unix binary package, do not include tools for Windows builds
        (and their manual pages).
        This does not affect source packages, of course.
      support-files/mysql.spec.sh:
        There were several files (binaries, scripts, and manuals)
        which got built with a RPM but never packages,
        add them to the respective RPM.
      8a5406a3
  2. 31 Jul, 2008 1 commit
  3. 30 Jul, 2008 1 commit
    • Georgi Kodinov's avatar
      Bug#37662 nested if() inside sum() is parsed in exponential time · 03805cbb
      Georgi Kodinov authored
            
      min() and max() functions are implemented in MySQL as macros.
      This means that max(a,b) is expanded to: ((a) > (b) ? (a) : (b))
      Note how 'a' is quoted two times.
      Now imagine 'a' is a recursive function call that's several 10s of levels deep.
      And the recursive function does max() with a function arg as well to dive into
      recursion.
      This means that simple function call can take most of the clock time.
      Identified and fixed several such calls to max()/min() : including the IF() 
      sql function implementation.
      
      mysql-test/r/func_if.result:
        Bug#37662 test case
      mysql-test/t/func_if.test:
        Bug#37662 test case
      sql/item.cc:
        Bug#37662 don't call expensive functions as arguments to min/max
      sql/item_cmpfunc.cc:
        Bug#37662 don't call expensive functions as arguments to min/max
      sql/item_func.cc:
        Bug#37662 don't call expensive functions as arguments to min/max
      03805cbb
  4. 28 Jul, 2008 1 commit
  5. 26 Jul, 2008 1 commit
    • Igor Babaev's avatar
      Fixed bug #38191. · 59229a6b
      Igor Babaev authored
      Calling List<Cached_item>::delete_elements for the same list twice
      caused a crash of the server in the function JOIN::cleaunup.
      Ensured that delete_elements() in JOIN::cleanup would be called only once.
      
      
      mysql-test/r/subselect.result:
        Added a test case for bug #38191.
      mysql-test/t/subselect.test:
        Added a test case for bug #38191.
      sql/sql_select.cc:
        Fixed bug #38191.
        Ensured that delete_elements() in JOIN::cleanup would be called only once.
      59229a6b
  6. 24 Jul, 2008 1 commit
  7. 23 Jul, 2008 1 commit
    • Georgi Kodinov's avatar
      Bug#37830 : ORDER BY ASC/DESC - no difference · 5cf6d460
      Georgi Kodinov authored
                        
      Range scan in descending order for c <= <col> <= c type of
      ranges was ignoring the DESC flag.
      However some engines like InnoDB have the primary key parts 
      as a suffix for every secondary key.
      When such primary key suffix is used for ordering ignoring 
      the DESC is not valid.
      But we generally would like to do this because it's faster.
                  
      Fixed by performing only reverse scan if the primary key is used.
      Removed some dead code in the process.
      
      mysql-test/r/innodb_mysql.result:
        Bug#37830 : test case
      mysql-test/t/innodb_mysql.test:
        Bug#37830 : test case
      sql/opt_range.cc:
        Bug#37830 : 
        - preserve and use used_key_parts to
          distinguish when a primary key suffix is used
        - removed some dead code
      sql/opt_range.h:
        Bug#37830 : 
        - preserve used_key_parts
        - dead code removed
      sql/sql_select.cc:
        Bug#37830 : Do only reverse order traversal
        if the primary key suffix is used.
      5cf6d460
  8. 22 Jul, 2008 1 commit
  9. 21 Jul, 2008 1 commit
  10. 24 Jul, 2008 1 commit
  11. 21 Jul, 2008 1 commit
  12. 19 Jul, 2008 2 commits
  13. 18 Jul, 2008 2 commits
  14. 17 Jul, 2008 2 commits
  15. 16 Jul, 2008 5 commits
  16. 15 Jul, 2008 3 commits
    • Sergey Petrunia's avatar
      Merge · 41743952
      Sergey Petrunia authored
      41743952
    • Kristofer Pettersson's avatar
      auto merge · 497eb43b
      Kristofer Pettersson authored
      497eb43b
    • Sergey Petrunia's avatar
      BUG#35478: sort_union() returns bad data when sort_buffer_size is hit · 04037f54
      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
      04037f54
  17. 14 Jul, 2008 3 commits
    • Marc Alff's avatar
      Merge · 67834221
      Marc Alff authored
      67834221
    • Marc Alff's avatar
      Bug#35577 (CREATE PROCEDURE causes either crash or syntax error depending on · 5ac2bf7c
      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)
      5ac2bf7c
    • Joerg Bruehe's avatar
      Merge main 5.0 into 5.0-build · 66eca1c2
      Joerg Bruehe authored
      66eca1c2
  18. 10 Jul, 2008 4 commits
    • Gleb Shchepa's avatar
      warning elimination · f1761fba
      Gleb Shchepa authored
      f1761fba
    • Gleb Shchepa's avatar
      warning elimination · c25208ba
      Gleb Shchepa authored
      c25208ba
    • Tatiana A. Nurnberg's avatar
      auto-merge · 7a65532f
      Tatiana A. Nurnberg authored
      7a65532f
    • Tatiana A. Nurnberg's avatar
      Bug#35848: UUID() returns UUIDs with the wrong time · c054c744
      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.
      c054c744
  19. 09 Jul, 2008 6 commits
  20. 08 Jul, 2008 2 commits