1. 12 Feb, 2007 1 commit
    • unknown's avatar
      Bug#24532 (The return data type of IS TRUE is different from similar · a475ed7c
      unknown 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.
      
      
      mysql-test/r/func_if.result:
        IF(x, unsigned, unsigned) should be unsigned.
      mysql-test/r/view.result:
        Preserve the semantic of 'X IS [NOT] (TRUE|FALSE)' boolean predicates.
      mysql-test/t/func_if.test:
        IF(x, unsigned, unsigned) should be unsigned.
      mysql-test/t/view.test:
        Preserve the semantic of 'X IS [NOT] (TRUE|FALSE)' boolean predicates.
      sql/item_cmpfunc.cc:
        Preserve the semantic of 'X IS [NOT] (TRUE|FALSE)' boolean predicates.
        IF(x, unsigned, unsigned) should be unsigned.
      sql/item_cmpfunc.h:
        Preserve the semantic of 'X IS [NOT] (TRUE|FALSE)' boolean predicates.
      sql/sql_yacc.yy:
        Preserve the semantic of 'X IS [NOT] (TRUE|FALSE)' boolean predicates.
      a475ed7c
  2. 06 Feb, 2007 1 commit
    • unknown's avatar
      Bug#12976 (stored procedures local variables of type bit) · 372fc7e4
      unknown authored
      Before this change, a local variables in stored procedures / stored functions
      or triggers, when declared with a type of bit(N), would not evaluate their
      value properly.
      
      The problem was that the data was incorrectly typed as a string,
      causing for example bit b'1', implemented as a byte 0x01, to be interpreted
      as a string starting with the character 0x01. This later would cause
      implicit conversions to integers or booleans to fail.
      
      The root cause of this problem was an incorrect translation between field
      types, like bit(N), and internal types used when representing values in Item
      objects.
      
      Also, before this change, the function HEX() would sometime print extra "0"
      characters when invoked with bit(N) values.
      
      With this fix, the type translation (sp_map_result_type, sp_map_item_type)
      has been changed so that bit(N) fields are represented with integer values.
      
      A consequence is that, for the function HEX(), when called with a stored
      procedure local variable of type bit(N) as argument, HEX() is provided with an
      integer instead of a string, and therefore does not print "0" padding.
      
      A test case for Bug 12976 was present in the test suite, and has been updated.
      
      
      mysql-test/r/sp-vars.result:
        Local stored procedure variables of type bit(N) are integer values.
      mysql-test/t/sp-vars.test:
        Local stored procedure variables of type bit(N) are integer values.
      sql/sp_head.cc:
        Local stored procedure variables of type bit(N) are integer values.
      372fc7e4
  3. 04 Feb, 2007 1 commit
    • unknown's avatar
      BUG#25897: Some queries are no longer possible after a CREATE VIEW · 86b715a7
      unknown authored
                 fails
      
      The bug was introduced with the push of the fix for bug#20953: after
      the error on view creation we never reset the error state, so some
      valid statements would give the same error after that.
      
      The solution is to properly reset the error state.
      
      
      mysql-test/r/view.result:
        Add result for bug#25897: Some queries are no longer possible after
        a CREATE VIEW fails.
      mysql-test/t/view.test:
        Add test case for bug#25897: Some queries are no longer possible after
        a CREATE VIEW fails.
      sql/sql_lex.cc:
        Add st_parsing_options::reset() method, call it from lex_start().
      sql/sql_lex.h:
        Add st_parsing_options::reset() method, call it from constructor.
      86b715a7
  4. 01 Feb, 2007 1 commit
  5. 30 Jan, 2007 2 commits
    • unknown's avatar
      Merge malff@bk-internal.mysql.com:/home/bk/mysql-5.0-runtime · 7687a272
      unknown authored
      into  weblab.(none):/home/marcsql/TREE/mysql-5.0-21904
      
      
      mysql-test/r/subselect.result:
        Auto merged
      mysql-test/t/subselect.test:
        Auto merged
      sql/item_subselect.cc:
        Auto merged
      sql/item_subselect.h:
        Auto merged
      sql/sql_yacc.yy:
        Auto merged
      7687a272
    • unknown's avatar
      Bug#21904 (parser problem when using IN with a double "(())") · a1e20e04
      unknown 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.
      
      
      mysql-test/r/subselect.result:
        Implement IN predicate special exceptions with subselects.
      mysql-test/t/subselect.test:
        Implement IN predicate special exceptions with subselects.
      sql/item_subselect.cc:
        Implement IN predicate special exceptions with subselects.
      sql/item_subselect.h:
        Implement IN predicate special exceptions with subselects.
      sql/sql_yacc.yy:
        Implement IN predicate special exceptions with subselects, cleanup.
      a1e20e04
  6. 25 Jan, 2007 3 commits
    • unknown's avatar
      Merge moonlight.home:/home/tomash/src/mysql_ab/mysql-5.0 · 74ac969d
      unknown authored
      into  moonlight.home:/home/tomash/src/mysql_ab/mysql-5.0-bug23527
      
      
      sql/sql_cache.cc:
        Auto merged
      74ac969d
    • unknown's avatar
      BUG#23527: set global query_cache_size can crash the server under · ef013268
      unknown authored
                 high load
      
      MySQL server could crash if two or more threads would initiate query
      cache resize at the moments very close in time.
      
      The problem was introduced with the fix of bug 21051 in 5.0 and 5.1:
      simultaneous query cache resizes would wait for the first one in
      progress, but then each thread would try to finish the operation,
      accessing the data that was already reset (attempt to dereference
      'bins' pointer, which may be NULL already).
      
      The solution is to check after synchronization if another thread has
      done the reset already (test 'query_cache_size > 0' again).
      
      No test case is provided because the bug is a subject to a race.
      
      
      sql/sql_cache.cc:
        We release 'structure_guard_mutex' in flush_cache(), so after the
        call we check if another thread had reset the cache before us.
      ef013268
    • unknown's avatar
      Merge bk-internal.mysql.com:/home/bk/mysql-5.0 · ea41474b
      unknown authored
      into  mockturtle.local:/home/dlenev/src/mysql-5.0-merge
      
      
      ea41474b
  7. 24 Jan, 2007 16 commits
  8. 23 Jan, 2007 12 commits
    • unknown's avatar
      Merge bk-internal.mysql.com:/home/bk/mysql-4.1-engines · 1f4d8ba0
      unknown authored
      into  chilla.local:/home/mydev/mysql-4.1-bug24607
      
      
      mysql-test/r/myisam.result:
        Auto merged
      mysql-test/t/myisam.test:
        Auto merged
      1f4d8ba0
    • unknown's avatar
      Merge bk-internal.mysql.com:/home/bk/mysql-5.0-engines · 4bec8b03
      unknown authored
      into  chilla.local:/home/mydev/mysql-5.0-bug24607
      
      
      mysql-test/r/myisam.result:
        Auto merged
      mysql-test/t/myisam.test:
        Auto merged
      4bec8b03
    • unknown's avatar
      Merge pnousiainen@bk-internal.mysql.com:/home/bk/mysql-5.0-ndb · 964f502c
      unknown authored
      into  clam.ndb.mysql.com:/export/space/pekka/ndb/version/my50-ndb
      
      
      964f502c
    • unknown's avatar
      Merge willster.(none):/home/stewart/Documents/MySQL/5.0/ndb · a7174850
      unknown authored
      into  willster.(none):/home/stewart/Documents/MySQL/5.0/bug25487
      
      
      a7174850
    • unknown's avatar
      Merge bk-internal.mysql.com:/home/bk/mysql-5.0-runtime · 5f544ed0
      unknown authored
      into  mockturtle.local:/home/dlenev/src/mysql-5.0-bg24491
      
      
      sql/item.h:
        Auto merged
      mysql-test/r/ps.result:
        Manual merge.
      mysql-test/t/ps.test:
        Manual merge.
      5f544ed0
    • unknown's avatar
      Merge mysql.com:/home/svoj/devel/mysql/BUG24401/mysql-4.1-engines · 2244a361
      unknown authored
      into  mysql.com:/home/svoj/devel/mysql/BUG24401/mysql-5.0-engines
      
      
      myisam/mi_open.c:
        Auto merged
      2244a361
    • unknown's avatar
      Proposed fix for bug#24491 "using alias from source table in insert ... · 1dead07d
      unknown authored
      on duplicate key".
      
      INSERT ... SELECT ... ON DUPLICATE KEY UPDATE which was used in
      stored routine or as prepared statement and which in its ON DUPLICATE
      KEY clause erroneously tried to assign value to a column mentioned only
      in its SELECT part was properly emitting error on the first execution
      but succeeded on the second and following executions.
      
      Code which is responsible for name resolution of fields mentioned in
      UPDATE clause (e.g. see select_insert::prepare()) modifies table list
      and Name_resolution_context used in this process. It uses
      Name_resolution_context_state::save_state/restore_state() to revert
      these modifications. Unfortunately those two methods failed to revert
      properly modifications to TABLE_LIST::next_name_resolution_table
      and this broke name resolution process for successive executions.
      
      This patch fixes Name_resolution_context_state::save_state/restore_state()
      in such way that it properly handles TABLE_LIST::next_name_resolution_table.
      
      
      mysql-test/r/ps.result:
        Added test case for bug#24491 "using alias from source table in insert ...
        on duplicate key"
      mysql-test/r/sp-error.result:
        Added test case for bug#24491 "using alias from source table in insert ...
        on duplicate key"
      mysql-test/t/ps.test:
        Added test case for bug#24491 "using alias from source table in insert ...
        on duplicate key"
      mysql-test/t/sp-error.test:
        Added test case for bug#24491 "using alias from source table in insert ...
        on duplicate key"
      sql/item.h:
        Name_resolution_context::save_state/restore_state():
          At the moment these methods are used only by code implementing
          INSERT and INSERT ... SELECT statements. This code doesn't modify
         'next_name_resolution_table' member of table list element
          corresponding to the first table of SELECT clause (pointed by
          'first_name_resolution_table'). But it modifies table list element
          corresponding to the target table of INSERT (pointed by 'table_list')
          So these methods were changed to reflect this.
      1dead07d
    • unknown's avatar
      ndb - bug#25562 use byte-size max_data_length() when setting blob part size · 25fb32ef
      unknown authored
      
      sql/ha_ndbcluster.cc:
        bug#25562 use byte-size max_data_length() when setting blob part size
      25fb32ef
    • unknown's avatar
      round up Transporter connect timeout · 68ab0996
      unknown authored
      
      ndb/src/common/transporter/Transporter.cpp:
        change so timeout is rounded up to nearest second
      68ab0996
    • unknown's avatar
      Bug #25487 deleting ndb_cluster_connection object takes long time · 8deeb2f9
      unknown authored
        
        aim is to:
        a) if set_connect_timeout called, timeout connect attempt (for retry on
        next call) after timeout period
        b) preserve existing blocking behaviour otherwise (for, e.g. mgmapi)
        
        Related to customer issue with long time deleting ndb_cluster_connection
        object. believe we're hanging on the connect(2) call until timeout (when
        we then realise we should exit the thread).
      
      
      ndb/include/mgmapi/mgmapi.h:
        add ndb_mgm_set_connect_timeout
      ndb/include/util/SocketClient.hpp:
        add timeout (seconds) for max time to wait for connection
      ndb/src/common/transporter/Transporter.cpp:
        set limit on amount of time we'll wait for tcp connect
      ndb/src/common/util/SocketClient.cpp:
        only try to connect for a maximum of timeout time
      ndb/src/mgmapi/mgmapi.cpp:
        add ndb_mgm_set_connect_timeout
      8deeb2f9
    • unknown's avatar
      ndb - bug#22013 · ab8355fa
      unknown authored
          Fix bug in event handling wrt early node shutdown
      
      
      ndb/src/mgmsrv/MgmtSrvr.cpp:
        Fix bug in event handling wrt early node shutdown
      ndb/src/ndbapi/ClusterMgr.cpp:
        Fix reportNodeFailed if only connected wo/ having received any API_REGCONF
      ndb/src/ndbapi/ClusterMgr.hpp:
        Fix reportNodeFailed if only connected wo/ having received any API_REGCONF
      ndb/src/ndbapi/SignalSender.cpp:
        Fix memleak
      ab8355fa
    • unknown's avatar
      bug#25746 ndb: 4209 error with 2 VARCHAR primary keys · 188899cd
      unknown authored
      - post review changes
      
      
      188899cd
  9. 22 Jan, 2007 3 commits