An error occurred fetching the project authors.
  1. 07 Mar, 2007 2 commits
    • kostja@bodhi.local's avatar
      A post merge fix. · ba60ccbf
      kostja@bodhi.local authored
      ba60ccbf
    • kostja@bodhi.local's avatar
      A fix for Bug#26750 "valgrind leak in sp_head" (and post-review · 86f02cd3
      kostja@bodhi.local authored
      fixes).
      
      The legend: on a replication slave, in case a trigger creation
      was filtered out because of application of replicate-do-table/
      replicate-ignore-table rule, the parsed definition of a trigger was not 
      cleaned up properly. LEX::sphead member was left around and leaked 
      memory. Until the actual implementation of support of 
      replicate-ignore-table rules for triggers by the patch for Bug 24478 it 
      was never the case that "case SQLCOM_CREATE_TRIGGER"
      was not executed once a trigger was parsed,
      so the deletion of lex->sphead there worked and the memory did not leak.
      
      The fix: 
      
      The real cause of the bug is that there is no 1 or 2 places where
      we can clean up the main LEX after parse. And the reason we 
      can not have just one or two places where we clean up the LEX is
      asymmetric behaviour of MYSQLparse in case of success or error. 
      
      One of the root causes of this behaviour is the code in Item::Item()
      constructor. There, a newly created item adds itself to THD::free_list
      - a single-linked list of Items used in a statement. Yuck. This code
      is unaware that we may have more than one statement active at a time,
      and always assumes that the free_list of the current statement is
      located in THD::free_list. One day we need to be able to explicitly
      allocate an item in a given Query_arena.
      Thus, when parsing a definition of a stored procedure, like
      CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
      we actually need to reset THD::mem_root, THD::free_list and THD::lex
      to parse the nested procedure statement (SELECT *).
      The actual reset and restore is implemented in semantic actions
      attached to sp_proc_stmt grammar rule.
      The problem is that in case of a parsing error inside a nested statement
      Bison generated parser would abort immediately, without executing the
      restore part of the semantic action. This would leave THD in an 
      in-the-middle-of-parsing state.
      This is why we couldn't have had a single place where we clean up the LEX
      after MYSQLparse - in case of an error we needed to do a clean up
      immediately, in case of success a clean up could have been delayed.
      This left the door open for a memory leak.
      
      One of the following possibilities were considered when working on a fix:
      - patch the replication logic to do the clean up. Rejected
      as breaks module borders, replication code should not need to know the
      gory details of clean up procedure after CREATE TRIGGER.
      - wrap MYSQLparse with a function that would do a clean up.
      Rejected as ideally we should fix the problem when it happens, not
      adjust for it outside of the problematic code.
      - make sure MYSQLparse cleans up after itself by invoking the clean up
      functionality in the appropriate places before return. Implemented in 
      this patch.
      - use %destructor rule for sp_proc_stmt to restore THD - cleaner
      than the prevoius approach, but rejected
      because needs a careful analysis of the side effects, and this patch is 
      for 5.0, and long term we need to use the next alternative anyway
      - make sure that sp_proc_stmt doesn't juggle with THD - this is a 
      large work that will affect many modules.
      
      Cleanup: move main_lex and main_mem_root from Statement to its
      only two descendants Prepared_statement and THD. This ensures that
      when a Statement instance was created for purposes of statement backup,
      we do not involve LEX constructor/destructor, which is fairly expensive.
      In order to track that the transformation produces equivalent 
      functionality please check the respective constructors and destructors
      of Statement, Prepared_statement and THD - these members were
      used only there.
      This cleanup is unrelated to the patch.
      86f02cd3
  2. 06 Mar, 2007 1 commit
  3. 02 Mar, 2007 2 commits
  4. 01 Mar, 2007 1 commit
  5. 28 Feb, 2007 1 commit
    • bar@mysql.com's avatar
      Bug#15126 character_set_database is not replicated (LOAD DATA INFILE need it) · dd0c43d5
      bar@mysql.com authored
      This patch fixes problem that LOAD DATA could use different
      character sets when loading files on master and on slave sides:
      - Adding replication of thd->variables.collation_database
      - Adding optional character set clause into LOAD DATA
      
      Note, the second way, with explicit CHARACTER SET clause
      should be the recommended way to load data using an alternative
      character set.
      The old way, using "SET @@character_set_database=xxx" should be
      gradually depricated.
      dd0c43d5
  6. 24 Feb, 2007 1 commit
    • evgen@moonbone.local's avatar
      item.cc: · 47ffb61f
      evgen@moonbone.local authored
        Post fix for bug#23800.
        The Item_field constructor now increases the select_n_where_fields counter.
      sql_yacc.yy:
        Post fix for bug#23800.
        Take into account fields that might be added by subselects.
      sql_lex.h:
        Post fix for bug#23800.
        Added the select_n_where_fields variable to the st_select_lex class.
      sql_lex.cc:
        Post fix for bug#23800.
        Initialization of the select_n_where_fields variable.
      47ffb61f
  7. 23 Feb, 2007 1 commit
  8. 19 Feb, 2007 1 commit
    • gkodinov/kgeorge@macbook.gmz's avatar
      Bug #25831: Deficiencies in INSERT ... SELECT ... field name resolving. · d17ad7b3
      gkodinov/kgeorge@macbook.gmz 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.
      d17ad7b3
  9. 13 Feb, 2007 1 commit
  10. 12 Feb, 2007 1 commit
    • malff/marcsql@weblab.(none)'s avatar
      Bug#24532 (The return data type of IS TRUE is different from similar · 4e556b23
      malff/marcsql@weblab.(none) authored
        operations)
      
      Before this change, the boolean predicates:
      - X IS TRUE,
      - X IS NOT TRUE,
      - X IS FALSE,
      - X IS NOT FALSE
      were implemented by expanding the Item tree in the parser, by using a
      construct like:
      Item_func_if(Item_func_ifnull(X, <value>), <value>, <value>)
      
      Each <value> was a constant integer, either 0 or 1.
      
      A bug in the implementation of the function IF(a, b, c), in
      Item_func_if::fix_length_and_dec(), would cause the following :
      
      When the arguments b and c are both unsigned, the result type of the
      function was signed, instead of unsigned.
      
      When the result of the if function is signed, space for the sign could be
      counted twice (in the max() expression for a signed argument, and in the
      total), causing the member max_length to be too high.
      
      An effect of this is that the final type of IF(x, int(1), int(1)) would be
      int(2) instead of int(1).
      
      With this fix, the problems found in Item_func_if::fix_length_and_dec()
      have been fixed.
      
      While it's semantically correct to represent 'X IS TRUE' with
      Item_func_if(Item_func_ifnull(X, <value>), <value>, <value>),
      there are however more problems with this construct.
      
      a)
      Building the parse tree involves :
      - creating 5 Item instances (3 ints, 1 ifnull, 1 if),
      - creating each Item calls my_pthread_getspecific_ptr() once in the operator
        new(size), and a second time in the Item::Item() constructor, resulting
        in a total of 10 calls to get the current thread.
      Evaluating the expression involves evaluating up to 4 nodes at runtime.
      This representation could be greatly simplified and improved.
      
      b)
      Transforming the parse tree internally with if(ifnull(...)) is fine as long
      as this transformation is internal to the server implementation.
      With views however, the result of the parse tree is later exposed by the
      ::print() functions, and stored as part of the view definition.
      Doing this has long term consequences:
      
      1)
      The original semantic 'X IS TRUE' is lost, and replaced by the
      if(ifnull(...)) expression. As a result, SHOW CREATE VIEW does not restore
      the original code.
      
      2)
      Should a future version of MySQL implement the SQL BOOLEAN data type for
      example, views created today using 'X IS NULL' can be exported using
      mysqldump, and imported again. Such views would be converted correctly and
      automatically to use a BOOLEAN column in the future version.
      With 'X IS TRUE' and the current implementations, views using these
      "boolean" predicates would not be converted during the export/import, and
      would use integer columns instead.
      The difference traces back to how SHOW CREATE VIEW preserves 'X IS NULL' but
      does not preserve the 'X IS TRUE' semantic.
      
      With this fix, internal representation of 'X IS TRUE' booleans predicates
      has changed, so that:
      - dedicated Item classes are created for each predicate,
      - only 1 Item is created to represent 1 predicate
      - my_pthread_getspecific_ptr() is invoked 1 time instead of 10
      - SHOW CREATE VIEW preserves the original semantic, and prints 'X IS TRUE'.
      
      Note that, because of the fix in Item_func_if, views created before this fix
      will:
      - correctly use a int(1) type instead of int(2) for boolean predicates,
      - incorrectly print the if(ifnull(...), ...) expression in SHOW CREATE VIEW,
      since the original semantic (X IS TRUE) has been lost.
      - except for the syntax used in SHOW CREATE VIEW, these views will operate
      properly, no action is needed.
      
      Views created after this fix will operate correctly, and will preserve the
      original code semantic in SHOW CREATE VIEW.
      4e556b23
  11. 07 Feb, 2007 1 commit
    • antony@ppcg5.local's avatar
      Bug#12204 · a3c3cda9
      antony@ppcg5.local authored
        "CONNECTION is a reserved keyword"
        Allow connection to be used as an ordinary identifier
        Tests included.
      a3c3cda9
  12. 02 Feb, 2007 1 commit
  13. 31 Jan, 2007 1 commit
    • gkodinov/kgeorge@macbook.gmz's avatar
      BUG#25575: ERROR 1052 (Column in from clause is ambiguous) with sub-join · 16d2d682
      gkodinov/kgeorge@macbook.gmz 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()).
      16d2d682
  14. 30 Jan, 2007 1 commit
    • malff/marcsql@weblab.(none)'s avatar
      Bug#21904 (parser problem when using IN with a double "(())") · f5ad4eed
      malff/marcsql@weblab.(none) authored
      Before this fix, a IN predicate of the form: "IN (( subselect ))", with two
      parenthesis, would be evaluated as a single row subselect: if the subselect
      returns more that 1 row, the statement would fail.
      
      The SQL:2003 standard defines a special exception in the specification,
      and mandates that this particular form of IN predicate shall be equivalent
      to "IN ( subselect )", which involves a table subquery and works with more
      than 1 row.
      
      This fix implements "IN (( subselect ))", "IN ((( subselect )))" etc
      as per the SQL:2003 requirement.
      
      All the details related to the implementation of this change have been
      commented in the code, and the relevant sections of the SQL:2003 spec
      are given for reference, so they are not repeated here.
      
      Having access to the spec is a requirement to review in depth this patch.
      f5ad4eed
  15. 28 Jan, 2007 1 commit
    • monty@mysql.com/narttu.mysql.fi's avatar
      After merge fixes · 410fc81a
      monty@mysql.com/narttu.mysql.fi authored
      Removed a lot of compiler warnings
      Removed not used variables, functions and labels
      Initialize some variables that could be used unitialized (fatal bugs)
      %ll -> %l
      410fc81a
  16. 24 Jan, 2007 1 commit
    • malff/marcsql@weblab.(none)'s avatar
      Bug#21029 (Dependencies between sql_yacc.cc and dependent headers not detected) · 3ae384d0
      malff/marcsql@weblab.(none) authored
      The build scripts in general, using automake, autoconf, etc, contain several
      special commands and work around all related to the way the bison code in the
      parser is built, for sql/sql_yacc.yy. These work arounds, accumulated over
      time during development, ultimately cause the build scripts to be unstable
      and cause build defects by not enforcing dependencies.
      
      This fix simplifies the build process and aligns it with the automake tooling,
      which provides native support for bison and *.yy files.
      
      In particular, the following problem have been fixed:
      - dependencies with sql_yacc.cc were not honored (Bug 21029), leading to
        corrupted builds,
      - the work around introduced by Bug 24557, to cleanup the generated files
        sql_yacc.h and sql_yacc.cc, has been removed,
      - the generated makefile, in a source distribution, used to destroy the files
        sql_yacc.h and sql_yacc.cc on a 'make clean' target. This has been fixed:
        these files are now removed by make maintainer-clean.
      - The root cause of the problem found with gcc 4.1 (see Bug 24619) has been
        clearly documented, and the "sed" hack has been replaced by a cleaner
        work around, when building the code with bison 1.875.
      - Removed the file sql/sql_yacc.yy.bak, added by WL 3031 by accident.
      - Removed the unnecessary AM_YFLAG= --debug introduced by WL 3432, since
        the compiling option DBUG_OFF takes precedence when setting YYDEBUG.
      3ae384d0
  17. 23 Jan, 2007 1 commit
    • malff/marcsql@weblab.(none)'s avatar
      Bug#24392 (SHOW ENGINE MUTEX STATUS is a synonym for SHOW INNODB STATUS) · 2bd3c8fd
      malff/marcsql@weblab.(none) authored
      Before this fix, the command SHOW ENGINE <name> STATUS would:
      - print a warning if the engine name is unknown,
      - proceed and implement the same behavior as SHOW ENGINE ALL STATUS,
      and list the status of all the storage engines registered.
      
      In particular, this behavior caused confusion about the command :
      SHOW ENGINE MUTEX STATUS, which as a side effect would print the status
      of the innodb engine when that engine is registered.
      
      Also, before this fix, every time an unknown engine name was substituted by
      the default engine (which happen unless SQL_MODE NO_ENGINE_SUBSTITUTION is
      set), a malformed warning was raised.
      For example, the command ALTER TABLE T1 ENGINE = X would print :
      Warnings:
      Error 1286 Unknown table engine 'X'
      
      With this fix:
      SHOW ENGINE <name> STATUS|LOGS|MUTEX
      always fails with an error when the engine <name> is unknown.
      
      For other commands, warnings about unknown engines are raised as:
      Warnings:
      Warning 1286 Unknown table engine 'X'
      
      In other words, engine substitution never affect the SHOW ENGINE command,
      since this would lead to very confusing results.
      2bd3c8fd
  18. 19 Jan, 2007 1 commit
  19. 18 Jan, 2007 1 commit
    • malff/marcsql@weblab.(none)'s avatar
      Bug#24562 (ALTER TABLE ... ORDER BY ... with complex expression asserts) · 436e1f59
      malff/marcsql@weblab.(none) authored
      WL#3681 (ALTER TABLE ORDER BY)
      
      Before this fix, the ALTER TABLE statement implemented an ORDER BY option
      with the following characteristics :
      
      1) The order by clause accepts a list of criteria, with optional ASC or
      DESC keywords
      
      2) Each criteria can be a general expression, involving operators,
      native functions, stored functions, user defined functions, subselects ...
      
      With this fix :
      
      1) has been left unchanged, since it's a de-facto existing feature,
      that was already present in the code base and partially covered in the test
      suite. Code coverage for ASC and DESC was missing and has been improved.
      
      2) has been changed to limit the kind of criteria that are permissible:
      now only a column name is valid.
      436e1f59
  20. 11 Jan, 2007 1 commit
    • malff/marcsql@weblab.(none)'s avatar
      Bug#22687 (Functions UNIQUE_USERS, GROUP_UNIQUE_USERS) · 9655f5fb
      malff/marcsql@weblab.(none) authored
      According to some internal communication, these two functions are place
      holders for future enhancements. Because they use a variable number of
      parameters, the implementation defined a reserved keyword for them in the
      parser grammar.
      
      Unfortunately, doing so creates a bug similar to Bug 21114 reported for the
      function FORMAT.
      
      In the 5.1 code base, due to improvements in the code implemented with bug
      21114, having a reserved keyword for functions with a variable number of
      arguments is not needed any more by the implementation.
      
      As a result, this fix removes the place-holder implementation, and removes
      the unnecessary reserved keywords. Should the functions UNIQUE_USERS and
      GROUP_UNIQUE_USERS be finally implemented in a later release, the
      implementation should sub class Create_native_func in sql/item_create.cc.
      For example, see the class Create_func_concat.
      9655f5fb
  21. 03 Jan, 2007 1 commit
    • malff/marcsql@weblab.(none)'s avatar
      Bug#25302 (893 reduce/reduce conflicts in parser grammar) · 4cae0119
      malff/marcsql@weblab.(none) authored
      This fix corrects build issues introduced by WL#3031:
      
      - In the SQL grammar, 'USER' is a SQL 2003 reserved keyword,
      and therefore should not be part of the keyword production.
      
      - In sql/sql_parse.cc, the code for CREATE SERVER and ALTER SERVER
      was not using proper format strings in the DBUG_PRINT statements.
      4cae0119
  22. 23 Dec, 2006 1 commit
  23. 19 Dec, 2006 1 commit
  24. 14 Dec, 2006 1 commit
    • monty@mysql.com/narttu.mysql.fi's avatar
      Fixed compiler warnings detected by option -Wshadow and -Wunused: · 88dd873d
      monty@mysql.com/narttu.mysql.fi authored
      - Removed not used variables and functions
      - Added #ifdef around code that is not used
      - Renamed variables and functions to avoid conflicts
      - Removed some not used arguments
      
      Fixed some class/struct warnings in ndb
      Added define IS_LONGDATA() to simplify code in libmysql.c
      
      I did run gcov on the changes and added 'purecov' comments on almost all lines that was not just variable name changes
      88dd873d
  25. 12 Dec, 2006 1 commit
  26. 11 Dec, 2006 2 commits
  27. 09 Dec, 2006 1 commit
    • patg@govinda.patg.net's avatar
      WL# 3031 · 98062f56
      patg@govinda.patg.net authored
      Post-commit issues fixed
      * Test results for other tests fixed due to added error #s
      * Memory allocation/free issues found with running with valgrind
      * Fix to mysql-test-run shell script to run federated_server test (installs
      mysql.servers table properly)
      98062f56
  28. 07 Dec, 2006 2 commits
    • kostja@bodhi.local's avatar
      A fix and test cases for · 90072e69
      kostja@bodhi.local authored
      Bug#4968 "Stored procedure crash if cursor opened on altered table"
      Bug#19733 "Repeated alter, or repeated create/drop, fails"
      Bug#19182 "CREATE TABLE bar (m INT) SELECT n FROM foo; doesn't work from 
      stored procedure."
      Bug#6895 "Prepared Statements: ALTER TABLE DROP COLUMN does nothing"
      Bug#22060 "ALTER TABLE x AUTO_INCREMENT=y in SP crashes server"
      
      Test cases for bugs 4968, 19733, 6895 will be added in 5.0.
      
      Re-execution of CREATE DATABASE, CREATE TABLE and ALTER TABLE 
      statements in stored routines or as prepared statements caused
      incorrect results (and crashes in versions prior to 5.0.25).
      In 5.1 the problem occured only for CREATE DATABASE, CREATE TABLE
      SELECT and CREATE TABLE with INDEX/DATA DIRECTOY options).
      
      The problem of bugs 4968, 19733, 19282 and 6895 was that functions
      mysql_prepare_table, mysql_create_table and mysql_alter_table were not
      re-execution friendly: during their operation they used to modify contents
      of LEX (members create_info, alter_info, key_list, create_list),
      thus making the LEX unusable for the next execution.
      In particular, these functions removed processed columns and keys from
      create_list, key_list and drop_list. Search the code in sql_table.cc 
      for drop_it.remove() and similar patterns to find evidence.
      
      The fix is to supply to these functions a usable copy of each of the
      above structures at every re-execution of an SQL statement. 
      
      To simplify memory management, LEX::key_list and LEX::create_list
      were added to LEX::alter_info, a fresh copy of which is created for
      every execution.
      
      The problem of crashing bug 22060 stemmed from the fact that the above 
      metnioned functions were not only modifying HA_CREATE_INFO structure in 
      LEX, but also were changing it to point to areas in volatile memory of 
      the execution memory root.
       
      The patch solves this problem by creating and using an on-stack
      copy of HA_CREATE_INFO (note that code in 5.1 already creates and
      uses a copy of this structure in mysql_create_table()/alter_table(),
      but this approach didn't work well for CREATE TABLE SELECT statement).
      90072e69
    • andrey@example.com's avatar
      Additional fix for bug#22369 · 12a68db3
      andrey@example.com authored
      12a68db3
  29. 04 Dec, 2006 2 commits
  30. 02 Dec, 2006 3 commits
    • malff/marcsql@weblab.(none)'s avatar
      Bug#24736: UDF functions parsed as Stored Functions · 88ba7676
      malff/marcsql@weblab.(none) authored
      Before this fix, a call to a User Defined Function (UDF) could,
      under some circumstances, be interpreted as a call to a Stored function
      instead. This occurred if a native function was invoked in the parameters
      for the UDF, as in "select my_udf(abs(x))".
      
      The root cause of this defect is the introduction, by the fix for Bug 21809,
      of st_select_lex::udf_list, and it's usage in the parser in sql_yacc.yy
      in the rule function_call_generic (in 5.1).
      
      While the fix itself for Bug 21809 is correct in 5.0, the code change
      merged into the 5.1 release created the issue, because the calls in 5.1 to :
      - lex->current_select->udf_list.push_front(udf)
      - lex->current_select->udf_list.pop()
      are not balanced in case of native functions, causing the udf_list,
      which is really a stack, to be out of sync with the internal stack
      maintained by the bison parser.
      
      Instead of moving the call to udf_list.pop(), which would have fixed the
      symptom, this patch goes further and removes the need for udf_list.
      
      This is motivated by two reasons:
      
      a) Maintaining a stack in the MySQL code in sync with the stack maintained
      internally in sql_yacc.cc (not .yy) is extremely dependent of the
      implementation of yacc/bison, and extremely difficult to maintain.
      It's also totally dependent of the structure of the grammar, and has a risk
      to break with regression defects each time the grammar itself is changed.
      
      b) The previous code did report construct like "foo(expr AS name)" as
      syntax errors (ER_PARSER_ERROR), which is incorrect, and misleading.
      The syntax is perfectly valid, as this expression is valid when "foo" is
      a UDF. Whether this syntax is legal or not depends of the semantic of "foo".
      
      With this change:
      
      a) There is only one stack (in bison), and no List<udf_func> to maintain.
      
      b) "foo(expr AS name)", when used incorrectly, is reported as semantic error:
      - ER_WRONG_PARAMETERS_TO_NATIVE_FCT (for native functions)
      - ER_WRONG_PARAMETERS_TO_STORED_FCT (for stored functions)
      This is achieved by the changes implemented in item_create.cc
      88ba7676
    • brian@zim.(none)'s avatar
      This finishes the work (someone) started to remove FIELD_ types and use the... · 31d67280
      brian@zim.(none) authored
      This finishes the work (someone) started to remove FIELD_ types and use the Enum MYSQL types. The second part to this is to actually deprecate the FIELD defines in mysql_com.h
      31d67280
    • patg@radha.tangent.org's avatar
      WL# 3031 · a3e85cce
      patg@radha.tangent.org authored
      Backport of functionality in private 5.2 tree. 
      
      Added new language to parser, new mysql.servers table and associated code
      to be used by the federated storage engine to allow central connection information
      per WL entry.
      a3e85cce
  31. 30 Nov, 2006 2 commits
    • monty@mysql.com/narttu.mysql.fi's avatar
      Fixed portability issue in my_thr_init.c (was added in my last push) · 3d409560
      monty@mysql.com/narttu.mysql.fi authored
      Fixed compiler warnings (detected by VC++):
      - Removed not used variables
      - Added casts
      - Fixed wrong assignments to bool
      - Fixed wrong calls with bool arguments
      - Added missing argument to store(longlong), which caused wrong store method to be called.
      3d409560
    • monty@mysql.com/narttu.mysql.fi's avatar
      Fixed compiler warnings (Mostly VC++): · 3a35c300
      monty@mysql.com/narttu.mysql.fi authored
      - Removed not used variables
      - Changed some ulong parameters/variables to ulonglong (possible serious bug)
      - Added casts to get rid of safe assignment from longlong to long (and similar)
      - Added casts to function parameters
      - Fixed signed/unsigned compares
      - Added some constructores to structures
      - Removed some not portable constructs
      
      Better fix for bug Bug #21428 "skipped 9 bytes from file: socket (3)" on "mysqladmin shutdown"
      (Added new parameter to net_clear() to define when we want the communication buffer to be emptied)
      3a35c300
  32. 29 Nov, 2006 1 commit
    • kroki/tomash@moonlight.intranet's avatar
      BUG#20637: "load data concurrent infile" locks the table · 50e3b321
      kroki/tomash@moonlight.intranet authored
      Note that we ignore CONCURRENT if LOAD DATA CONCURRENT is used from
      inside a stored routine and MySQL is compiled with Query Cache support
      (this is not in the manual).
      
      The problem was that the condition test of "we are inside stored routine"
      was reversed, thus CONCURRENT _worked only_ from stored routine.  The
      solution is to use proper condition test.
      
      No test case is provided because the test case would require a large
      amount of input, and it's hard to tell is SELECT is really blocked or
      just slow (subject to race).
      50e3b321