1. 04 Feb, 2011 3 commits
  2. 02 Feb, 2011 11 commits
    • Georgi Kodinov's avatar
      merge · 5ba1fe97
      Georgi Kodinov authored
      5ba1fe97
    • Georgi Kodinov's avatar
      merge · 3b65062d
      Georgi Kodinov authored
      3b65062d
    • Georgi Kodinov's avatar
      merge · 63a40fe6
      Georgi Kodinov authored
      63a40fe6
    • Georgi Kodinov's avatar
      6954b672
    • Georgi Kodinov's avatar
      merge to 5.1. · ac3243c8
      Georgi Kodinov authored
      ac3243c8
    • Georgi Kodinov's avatar
      Fixes for Bug #55755 and Bug #52315 part 2 · 59f68983
      Georgi Kodinov authored
      Bug #55755 : Date STD variable signness breaks server on FreeBSD and OpenBSD
      
      * Added a check to configure on the size of time_t
      * Created a macro to check for a valid time_t that is safe to use with datetime 
        functions and store in TIMESTAMP columns.
      * Used the macro consistently instead of the ad-hoc checks introduced by 52315
      * Fixed compliation warnings on platforms where the size of time_t is smaller than
        the size of a long (e.g. OpenBSD 4.8 64 amd64).
      
      Bug #52315: utc_date() crashes when system time > year 2037
      
      * Added a correct check for the timestamp range instead of just variable size check to
      SET TIMESTAMP.
      * Added overflow checking before converting to time_t. 
      * Using a correct localized error message in this case instead of the generic error.
      * Added a test suite.
      * fixed the checks so that they check for unsigned time_t as well. Used the checks 
        consistently across the source code.
      * fixed the original test case to expect the new error code.
      59f68983
    • Dmitry Lenev's avatar
      Merged fix for bug #58650 "Failing assertion: · 9b3884e9
      Dmitry Lenev authored
      primary_key_no == -1 || primary_key_no == 0"
      with recent changes from mysql-5.5 tree.
      9b3884e9
    • Dmitry Lenev's avatar
      Merged fix for bug #58650 "Failing assertion: · 3be9d742
      Dmitry Lenev authored
      primary_key_no == -1 || primary_key_no == 0"
      into mysql-5.5 tree.
      3be9d742
    • Dmitry Lenev's avatar
      Fix for bug #58650 "Failing assertion: primary_key_no == -1 || · 3473329d
      Dmitry Lenev authored
      primary_key_no == 0".
      
      Attempt to create InnoDB table with non-nullable column of
      geometry type having an unique key with length 12 on it and
      with some other candidate key led to server crash due to
      assertion failure in both non-debug and debug builds.
      
      The problem was that such a non-candidate key could have
      been sorted as the first key in table/.FRM, before any legit
      candidate keys. This resulted in assertion failure in InnoDB
      engine which assumes that primary key should either be the
      first key in table/.FRM or should not exist at all.
      
      The reason behind such an incorrect sorting was an wrong
      value of Create_field::key_length member for geometry field
      (which was set to its pack_length == 12) which confused code
      in mysql_prepare_create_table(), so it would skip marking
      such key as a key with partial segments.
      
      This patch fixes the problem by ensuring that this member
      gets the same value of Create_field::key_length member as 
      for other blob fields (from which geometry field class is
      inherited), and as result unique keys on geometry fields
      are correctly marked as having partial segments.
      3473329d
    • Tor Didriksen's avatar
      Bug #36022 please log more information about "Sort aborted" queries · 207e5321
      Tor Didriksen authored
      Write an additional warning message to the server log, 
      explaining why a sort operation is aborted.
      
      The output in mysqld.err will look something like:
      110127 15:07:54 [ERROR] mysqld: Sort aborted: Out of memory (Needed 24 bytes)
      110127 15:07:54 [ERROR] mysqld: Out of sort memory, consider increasing server sort buffer size
      110127 15:07:54 [ERROR] mysqld: Sort aborted: Out of sort memory, consider increasing server sort buffer size
      110127 15:07:54 [ERROR] mysqld: Sort aborted: Incorrect number of arguments for FUNCTION test.f1; expected 0, got 1
      
      If --log-warn=2 is enabled, we output information about host/user/query as well.
      207e5321
    • Tor Didriksen's avatar
      Backport of fix for Bug#52123 · d6ed8398
      Tor Didriksen authored
      d6ed8398
  3. 01 Feb, 2011 3 commits
    • Ole John Aske's avatar
      Fix for bug#58490, 'Incorrect result in multi level OUTER JOIN · 1d6261c5
      Ole John Aske authored
      in combination with IS NULL'
            
      As this bug is a duplicate of bug#49322, it also includes test cases
      covering this bugreport
            
      Qualifying an OUTER JOIN with the condition 'WHERE <column> IS NULL',
      where <column> is declared as 'NOT NULL' causes the
      'not_exists_optimize' to be enabled by the optimizer.
            
      In evaluate_join_record() the 'not_exists_optimize' caused
      'NESTED_LOOP_NO_MORE_ROWS' to be returned immediately
      when a matching row was found.
            
      However, as the 'not_exists_optimize' is derived from
      'JOIN_TAB::select_cond', the usual rules for condition guards
      also applies for 'not_exist_optimize'. It is therefore incorrect
      to check 'not_exists_optimize' without ensuring that all guards
      protecting it is 'open'.
            
      This fix uses the fact that 'not_exists_optimize' is derived from
      a 'is_null' predicate term in 'tab->select_cond'. Furthermore,
      'is_null' will evaluate to 'false' for any 'non-null' rows
      once all guards protecting the is_null is open.
            
      We can use this knowledge as an implicit guard check for the
      'not_exists_optimize' by moving 'if (...not_exists_optimize)'
      inside the handling of 'select_cond==false'. It will then
      not take effect before its guards are open.
            
      We also add an assert which requires that a
      'not_exists_optimize' always comes together with
      a select_cond. (containing 'is_null').
      1d6261c5
    • Ole John Aske's avatar
      Merge · 83817644
      Ole John Aske authored
      83817644
    • Ole John Aske's avatar
      Fix for bug#57030: ('BETWEEN' evaluation is incorrect') · c8de3bba
      Ole John Aske authored
                  
      Root cause for this bug is that the optimizer try to detect&
      optimize the special case:
            
      '<field>  BETWEEN c1 AND c1' and handle this as the condition '<field>  = c1'
                  
      This was implemented inside add_key_field(.. *field, *value[]...)
      which assumed field to refer key Field, and value[] to refer a [low...high]
      constant pair. value[0] and value[1] was then compared for equality.
                  
      In a 'normal' BETWEEN condition of the form '<field>  BETWEEN val1 and val2' the
      BETWEEN operation is represented with an argementlist containing the
      values [<field>, val1, val2] - add_key_field() is then called with
      parameters field=<field>, *value=val1.
                  
      However, if the BETWEEN predicate specified:
                  
       1)  '<const1>  BETWEEN<const2>  AND<field>
                  
      the 'field' and 'value' arguments to add_key_field() had to be swapped.
      This was implemented by trying to cheat add_key_field() to handle it like:
                  
       2) '<const1>  GE<const2>  AND<const1>  LE<field>'
                  
      As we didn't really replace the BETWEEN operation with 'ge' and 'le',
      add_key_field() still handled it as a 'BETWEEN' and compared the (swapped)
      arguments<const1>  and<const2>  for equality. If they was equal, the
      condition 1) was incorrectly 'optimized' to:
                  
       3) '<field>  EQ <const1>'
                  
      This fix moves this optimization of '<field>  BETWEEN c1 AND c1' into
      add_key_fields() which then calls add_key_equal_fields() to collect 
      key equality / comparison for the key fields in the BETWEEN condition.
      c8de3bba
  4. 31 Jan, 2011 9 commits
  5. 30 Jan, 2011 4 commits
  6. 29 Jan, 2011 5 commits
  7. 28 Jan, 2011 5 commits