An error occurred fetching the project authors.
  1. 23 Feb, 2007 4 commits
  2. 20 Feb, 2007 1 commit
    • anozdrin/alik@alik.opbmk's avatar
      Fix for BUG#24415: Instance manager test im_daemon_life_cycle fails randomly. · 76f813a5
      anozdrin/alik@alik.opbmk authored
      The cause of im_daemon_life_cycle.imtest random failures was the following
      behaviour of some implementations of LINUX threads: let's suppose that a
      process has several threads (in LINUX threads, there is a separate process for
      each thread). When the main process gets killed, the parent receives SIGCHLD
      before all threads (child processes) die. In other words, the parent receives
      SIGCHLD, when its child is not completely dead.
      
      In terms of IM, that means that IM-angel receives SIGCHLD when IM-main is not dead
      and still holds some resources. After receiving SIGCHLD, IM-angel restarts
      IM-main, but IM-main failed to initialize, because previous instance (copy) of
      IM-main still holds server socket (TCP-port).
      
      Another problem here was that IM-angel restarted IM-main only if it was killed
      by signal. If it exited with error, IM-angel thought it's intended / graceful
      shutdown and exited itself.
      
      So, when the second instance of IM-main failed to initialize, IM-angel thought
      it's intended shutdown and quit.
      
      The fix is
        1. to change IM-angel so that it restarts IM-main if it exited with error code;
        2. to change IM-main so that it returns proper exit code in case of failure.
      76f813a5
  3. 19 Feb, 2007 4 commits
  4. 16 Feb, 2007 2 commits
  5. 14 Feb, 2007 1 commit
  6. 13 Feb, 2007 7 commits
  7. 12 Feb, 2007 17 commits
    • holyfoot/hf@mysql.com/hfmain.(none)'s avatar
      Merge mysql.com:/home/hf/work/20691/my50-20691 · 30614d22
      holyfoot/hf@mysql.com/hfmain.(none) authored
      into  mysql.com:/home/hf/work/25492/my50-25492
      30614d22
    • holyfoot/hf@mysql.com/hfmain.(none)'s avatar
      Merge bk@192.168.21.1:mysql-5.0-opt · fb4ad239
      holyfoot/hf@mysql.com/hfmain.(none) authored
      into  mysql.com:/home/hf/work/25492/my50-25492
      fb4ad239
    • holyfoot/hf@mysql.com/hfmain.(none)'s avatar
      Merge mysql.com:/home/hf/work/25492/my41-25492 · 74cbe92c
      holyfoot/hf@mysql.com/hfmain.(none) authored
      into  mysql.com:/home/hf/work/25492/my50-25492
      74cbe92c
    • 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
    • holyfoot/hf@mysql.com/hfmain.(none)'s avatar
    • gluh@mysql.com/eagle.(none)'s avatar
      Merge mysql.com:/home/gluh/MySQL/Merge/5.0 · 674868da
      gluh@mysql.com/eagle.(none) authored
      into  mysql.com:/home/gluh/MySQL/Merge/5.0-opt
      674868da
    • gluh@mysql.com/eagle.(none)'s avatar
      Merge sgluhov@bk-internal.mysql.com:/home/bk/mysql-5.0-opt · 81d4297d
      gluh@mysql.com/eagle.(none) authored
      into  mysql.com:/home/gluh/MySQL/Merge/5.0-opt
      81d4297d
    • gluh@mysql.com/eagle.(none)'s avatar
      valgrind error fix · 6caff6f7
      gluh@mysql.com/eagle.(none) authored
      6caff6f7
    • gkodinov/kgeorge@macbook.gmz's avatar
      Fixed MacOSX/Intel linking problem · 35a84c0a
      gkodinov/kgeorge@macbook.gmz authored
       Common symbols with and without initialization
       cause the apple linker to exclude then from the
       list of global symbols.
      35a84c0a
    • tnurnberg@mysql.com/sin.azundris.com's avatar
      Merge tnurnberg@bk-internal.mysql.com:/home/bk/mysql-5.0-maint · 293352cb
      tnurnberg@mysql.com/sin.azundris.com authored
      into  mysql.com:/home/tnurnberg/24660/50-24660
      293352cb
    • tnurnberg@mysql.com/sin.azundris.com's avatar
      Merge tnurnberg@bk-internal.mysql.com:/home/bk/mysql-4.1-maint · 8dc8e07f
      tnurnberg@mysql.com/sin.azundris.com authored
      into  mysql.com:/home/tnurnberg/24660/41-24660
      8dc8e07f
    • tnurnberg@mysql.com/sin.azundris.com's avatar
      Merge mysql.com:/home/tnurnberg/24660/41-24660 · ed82b013
      tnurnberg@mysql.com/sin.azundris.com authored
      into  mysql.com:/home/tnurnberg/24660/50-24660
      ed82b013
    • tnurnberg@mysql.com/sin.azundris.com's avatar
      Bug#24660: "enum" field type definition problem · db7ac2c0
      tnurnberg@mysql.com/sin.azundris.com authored
      ENUMs weren't allowed to have character 0xff, a perfectly good character in some locales.
      This was circumvented by mapping 0xff in ENUMs to ',', thereby prevent actual commas from
      being used. Now if 0xff makes an appearance, we find a character not used in the enum and
      use that as a separator. If no such character exists, we throw an error.
      
      Any solution would have broken some sort of existing behaviour. This solution should
      serve both fractions (those with 0xff and those with ',' in their enums), but
      WILL REQUIRE A DUMP/RESTORE CYCLE FROM THOSE WITH 0xff IN THEIR ENUMS. :-/
      That is, mysqldump with their current server, and restore when upgrading to one with
      this patch.
      db7ac2c0
    • gluh@mysql.com/eagle.(none)'s avatar
      Bug#24630 Subselect query crashes mysqld · 47e537b4
      gluh@mysql.com/eagle.(none) authored
      The crash happens because second filling of the same I_S table happens in
      case of subselect with order by. table->sort.io_cache previously allocated
      in create_sort_index() is deleted during second filling
      (function get_schema_tables_result). There are two places where
      I_S table can be filled: JOIN::exec and create_sort_index().
      To fix the bug we should check if the table was already filled
      in one of these places and skip processing of the table in second.
      47e537b4
    • holyfoot/hf@mysql.com/hfmain.(none)'s avatar
      bug #20691 (INSERT (DEFAULT) may insert garbage with NO DEFAULT NOT NULL field) · 8299b596
      holyfoot/hf@mysql.com/hfmain.(none) authored
      Some fields (GEOMETRY first of all) can't be handled properly in this
      case at all. So we return an error in this case
      8299b596
    • igor@olga.mysql.com's avatar
      Merge olga.mysql.com:/home/igor/mysql-5.0-opt · 0583c7c5
      igor@olga.mysql.com authored
      into  olga.mysql.com:/home/igor/dev-opt/mysql-5.0-opt-bug26159
      0583c7c5
    • igor@olga.mysql.com's avatar
      Fixed bug #26209. · 4b1a1d9e
      igor@olga.mysql.com authored
      The function make_unireg_sortorder ignored the fact that any
      view field is represented by a 'ref' object.
      This could lead to wrong results for the queries containing
      both GROUP BY and ORDER BY clauses.
      4b1a1d9e
  8. 11 Feb, 2007 3 commits
  9. 09 Feb, 2007 1 commit
    • evgen@moonbone.local's avatar
      Bug#12122: The MERGE algorithm isn't applicable if the ORDER BY clause is · a2414463
      evgen@moonbone.local authored
      present.
      
      A view created with CREATE VIEW ... ORDER BY ... cannot be resolved with
      the MERGE algorithm, even when no other part of the CREATE VIEW statement
      would require the view to be resolved using the TEMPTABLE algorithm.
      
      The check for presence of the ORDER BY clause in the underlying select is 
      removed from the st_lex::can_be_merged() function.
      The ORDER BY list of the underlying select is appended to the ORDER BY list 
      a2414463