1. 02 Jun, 2017 1 commit
  2. 30 May, 2017 2 commits
    • Monty's avatar
      MDEV-12930 Testing SEQUENCE object · 95989166
      Monty authored
      Fixed the following things from the above MDEV:
      - Ensure the user has INSERT privilege when generating new sequence values
        with NEXT VALUE FOR or SETVAL()
      - Fixed bug in InnoDB when generating several sequence values in one statement
      - Ensure that read_set is up to date before calling ha_sequence::ha_write_row()
        - This is only a potential bug with storage engines that trusts the column maps completely
      95989166
    • Monty's avatar
      Updated test case · d5d8fa6e
      Monty authored
      d5d8fa6e
  3. 29 May, 2017 4 commits
  4. 27 May, 2017 7 commits
  5. 26 May, 2017 2 commits
  6. 25 May, 2017 3 commits
    • Alexander Barkov's avatar
      A cleanup for MDEV-11514, MDEV-11497, MDEV-11554, MDEV-11555 - IN and CASE... · e1f81822
      Alexander Barkov authored
      A cleanup for MDEV-11514, MDEV-11497, MDEV-11554, MDEV-11555 - IN and CASE type aggregation problems
      
      Removing cmp_item::get_comparator() and calling instead
      Type_handler::make_cmp_item(), which was earlier introduced by this patch:
      
      74891ed2
      e1f81822
    • Alexander Barkov's avatar
      Fixing a few data type related problems: MDEV-12875, MDEV-12886, MDEV-12916 · 109bc470
      Alexander Barkov authored
      This is a joint patch fixing the following problems:
      
      MDEV-12875 Wrong VIEW column data type for COALESCE(int_column)
      MDEV-12886 Different default for INT and BIGINT column in a VIEW for a SELECT with ROLLUP
      MDEV-12916 Wrong column data type for an INT field of a cursor-anchored ROW variable
      
      All above problem happened because the global function ::create_tmp_field()
      called the top-level Item::create_tmp_field(), which made some tranformation
      for INT-result data types. For example, INT(11) became BIGINT(11), because 11
      is a corner case and it's not known if it fits or does not fit into INT range,
      so Item::create_tmp_field() converted it to BIGINT(11) for safety.
      
      The main idea of this patch is to avoid such tranformations.
      
      1. Fixing Item::create_tmp_field() not to have a special case for INT_RESULT.
      
         Item::create_tmp_field() is changed not to have a special case
         for INT_RESULT (which earlier made a decision based on Item's max_length).
         It now calls tmp_table_field_from_field_type() for INT_RESULT,
         therefore preserves the original data type (e.g. INT, YEAR) without
         conversion to BIGINT.
      
         This change is valid, because a number of recent fixes
         (e.g. in Item_func_int, Item_hybrid_func, Item_int, Item_splocal)
         guarantee that item->type_handler() now properly returns
         type_handler_long vs type_handler_longlong. So no adjustment by length
         is needed any more for Items returning INT_RESULT.
      
         After this change, Item::create_tmp_field() calls
         tmp_table_field_from_field_type() for all XXX_RESULT, except REAL_RESULT.
      
      2. Fixing Item::create_tmp_field() not to have a special case for REAL_RESULT.
      
         Note, the reason for a special case for REAL_RESULT is to have a special
         constructor for Field_double(), forcing Field_real::not_fixed to be set
         to true.
      
         Taking into account that only Item_sum descendants actually need a special
         constructor call Field_double(not_fixed=true), not too loose precision
         when mixing individual rows to the aggregate result:
         - renaming Item::create_tmp_field() to Item_sum::create_tmp_field().
         - changing Item::create_tmp_field() just to call
           tmp_table_field_from_field_type() for all XXX_RESULT types.
      
         A special case for REAL_RESULT in Item::create_tmp_field() is now gone.
         Item::create_tmp_field() is now symmetric for all XXX_RESULT types,
         and now just calls tmp_table_field_from_field_type().
      
      3. Fixing Item_func::create_field_for_create_select() not to have
         a special case for STRING_RESULT.
      
         After changes #1 and #2, the code in
         Item_func::create_field_for_create_select(), testing result_type(),
         becomes useless, because: now Item::create_tmp_field() and
         tmp_table_field_from_field_type() do exactly the same thing for all
         XXX_RESULT types for Item_func descendants:
         a. It calls tmp_table_field_from_field_type for STRING_RESULT directly.
         b. For other XXX_RESULT, it goes through Item::create_tmp_field(),
            which calls the global function ::create_tmp_field(),
            which calls item->create_tmp_field() for FUNC_ITEM,
            which calls tmp_table_field_from_field_type() again.
      
         So removing the virtual implementation of
         Item_func::create_field_for_create_select().
         The inherited Item::create_field_for_create_select() now perfectly
         does the job, as it also calls tmp_table_field_from_field_type()
         for FUNC_ITEM, independently from XXX_RESULT type.
      
      4. Taking into account #1 and #2, as well as some recent changes,
         removing virtual implementations:
         - Item_hybrid_func::create_tmp_field()
         - Item_hybrid_func::create_field_for_create_select()
         - Item_int_func::create_tmp_field()
         - Item_int_func::create_field_for_create_select()
         - Item_temporal_func::create_field_for_create_select()
         The derived versions from Item now perfectly work.
      
      5. Moving a piece of code from create_tmp_field_from_item()
         to a new function create_tmp_field_from_item_finalize(),
         to reuse it in two places (see #6).
      
      6. Changing the code responsible for BIT->INT/BIGIN tranformation
         (which is called for the cases when the created table, e.g. HEAP,
          does not fully support BIT) not to call create_tmp_field_from_item(),
         because the latter now calls tmp_table_field_from_field_type() instead
         of create_tmp_field() and thefore cannot do BIT transformation.
         So rewriting this code using a sequence of these calls:
         - item->type_handler_long_or_longlong()
         - handler->make_and_init_table_field()
         - create_tmp_field_from_item_finalize()
      
      7. Miscelaneous changes:
         - Moving type_handler_long_or_longlong() from "protected" to "public",
           as it's now needed in the global function create_tmp_field().
      
      8. The above changes fixed MDEV-12875, MDEV-12886, MDEV-12916.
         So adding tests for these bugs.
      109bc470
    • Alexander Barkov's avatar
      Adding tests for MDEV-12917 Wrong data type for CREATE..SELECT year_sp_variable · 54e29712
      Alexander Barkov authored
      The fix for MDEV-12876 fixed this problem as well.
      So adding tests only.
      54e29712
  7. 24 May, 2017 5 commits
    • Monty's avatar
      More tests for SEQUENCE's · a4789f52
      Monty authored
      - Test with LOCK TABLES
      - Test mysqldump
      - Don't update rows for sequence tables if values doesn't change. This is
        needed as InnoDB gives an error for updates where values doesn't change.
      a4789f52
    • Marko Mäkelä's avatar
      Follow-up fixes for MDEV-10139 Support for InnoDB SEQUENCE objects · 8acf4d6f
      Marko Mäkelä authored
      Because SEQUENCE objects or NO_ROLLBACK tables do not support locking
      or MVCC or transactions, avoid starting a transaction.
      
      row_upd_step(): Do not start a transaction. Let the caller do that.
      
      que_thr_step(): Call trx_start_if_not_started_xa() for QUE_NODE_UPDATE.
      (The InnoDB SQL parser is not used for accessing NO_ROLLBACK tables.)
      
      row_ins_step(): Correct a too strict assertion and comment about
      concurrency. Multiple concurrent readers are allowed.
      
      row_update_for_mysql_using_upd_graph(): Do not start the transaction
      for NO_ROLLBACK tables.
      
      row_search_mvcc(): For NO_ROLLBACK tables, skip locking even inside
      LOCK TABLES. Only call trx_start_if_not_started() at the start
      of a statement, not for each individual request.
      8acf4d6f
    • Monty's avatar
      Fixed failing test sql_sequence.replication · 9497a646
      Monty authored
      9497a646
    • Monty's avatar
      Simple replication test for sequences · d60e5fe3
      Monty authored
      d60e5fe3
    • Alexander Barkov's avatar
  8. 23 May, 2017 4 commits
    • Alexander Barkov's avatar
      90f06818
    • Alexander Barkov's avatar
      A cleanup for the patch for MDEV-12852, MDEV-12853, MDEV-12869 · 62b62319
      Alexander Barkov authored
      The patch broke expressions like CAST(1.0e+300 AS SIGNED INT)
      in binary protocol, e.g.:
        mtr --ps cast
      
      Short real numbers like 1.0e+300 can return huge values,
      so using args[0]->max_length is not reliable to choose properly the result
      type for Item_func_signed and Item_func_unsigned (between INT and BIGINT).
      
      Setting Item_[un]signed_typecast::max_length to MAX_BIGINT_WIDTH
      when doing CAST from FLOAT/DOUBLE, to force type_handler() return
      &type_handler_longlong rather than &type_handler_long.
      62b62319
    • Monty's avatar
      Make SEQUENCE working with replication · 6a779a6d
      Monty authored
      - Old sequence code forced row based replication for any statements that
        refered to a sequence table. What is new is that row based replication
        is now sequence aware:
         - NEXT VALUE is now generating a short row based event with only
           next_value and round being replicated.
         - Short row based events are now on the slave updated as trough
           SET_VALUE(sequence_name)
         - Full row based events are on the slave updated with a full insert,
           which is practically same as ALTER SEQUENCE.
      - INSERT on a SEQUENCE table does now a EXCLUSIVE LOCK to ensure that
        it is logged in binary log before any following NEXT VALUE calls.
      - Enable all sequence tests and fixed found bugs
      - ALTER SEQUENCE doesn't anymore allow changes that makes the next_value
        outside of allowed range
      - SEQUENCE changes are done with TL_WRITE_ALLOW_WRITE. Because of this
        one can generate a statement for MyISAM with both
        TL_WRITE_CONCURRENT_INSERT and TL_WRITE_ALLOW_WRITE. To fix a warning
        I had to add an extra test in thr_lock.c for this.
      - Removed UPDATE of SEQUENCE (no need to support this as we
        have ALTER SEQUENCE, which takes the EXCLUSIVE lock properly.
      - Removed DBUG_ASSERT() in MDL_context::upgrade_shared_lock. This was
        removed upstream in MySQL 5.6 in 72f823de453.
      - Simplified test in decided_logging_format() by using sql_command_flags()
      - Fix that we log DROP SEQUENCE correctly.
      - Fixed that Aria works with SEQUENCE
      6a779a6d
    • Alexander Barkov's avatar
      Fixing a few problems with data type and metadata for INT result functions... · d9304914
      Alexander Barkov authored
      Fixing a few problems with data type and metadata for INT result functions (MDEV-12852, MDEV-12853, MDEV-12869)
      
      This is a joint patch for:
      MDEV-12852 Out-of-range errors when CAST(1-2 AS UNSIGNED
      MDEV-12853 Out-of-range errors when CAST('-1' AS UNSIGNED
      MDEV-12869 Wrong metadata for integer additive and multiplicative operators
      
      1. Fixing all Item_func_numhybrid descendants to set the precise
         data type handler (type_handler_long or type_handler_longlong)
         at fix_fields() time. This fixes MDEV-12869.
      
      2. Fixing Item_func_unsigned_typecast to set the precise data type handler
         at fix_fields() time. This fixes MDEV-12852 and MDEV-12853.
         This is done by:
         - fixing Type_handler::Item_func_unsigned_fix_length_and_dec()
           and Type_handler_string_result::Item_func_unsigned_fix_length_and_dec()
           to properly detect situations when a negative epxression is converted
           to UNSIGNED. In this case, length of the result is now always set to
           MAX_BIGINT_WIDTH without trying to use args[0]->max_length, as very
           short arguments can produce very long result in such conversion:
              CAST(-1 AS UNSIGNED) -> 18446744073709551614
         - adding a new virtual method "longlong Item::val_int_max() const",
           to preserve the old behavior for expressions like this:
              CAST(1 AS UNSIGNED)
           to stay under the INT data type (instead of BIGINT) for small
           positive integer literals. Using Item::unsigned_flag would not help,
           because Item_int does not set unsigned_flag to "true" for positive
           numbers.
      
      3. Adding helper methods:
        * Item::type_handler_long_or_longlong()
        * Type_handler::type_handler_long_or_longlong()
        and reusing them in a few places, to reduce code duplication.
      
      4. Making reorganation in create_tmp_field() and
         create_field_for_create_select() for Item_hybrid_func and descendants,
         to reduce duplicate code. They all now have a similar behavior in
         respect of creating fields. Only Item_func_user_var descendants have
         a different behavior. So moving the default behvior to Item_hybrid_func,
         and overriding behavior on Item_func_user_var level.
      d9304914
  9. 22 May, 2017 3 commits
    • Alexander Barkov's avatar
    • Alexander Barkov's avatar
      MDEV-12858 + MDEV+12859 + MDEV-12862 - a join patch fixing a few data type... · c84bbeda
      Alexander Barkov authored
      MDEV-12858 + MDEV+12859 + MDEV-12862 - a join patch fixing a few data type problems with CREATE..SELECT
      
      MDEV-12858 Out-of-range error for CREATE..SELECT unsigned_int_column+1
      MDEV-12859 Out-of-range error for CREATE..SELECT @A:=EXTRACT(MINUTE_MICROSECOND FROM..)
      MDEV-12862 Data type of @A:=1e0 depends on the session character set
      
      1. Moving a part of Item::create_tmp_field() into a new helper method
         Item::create_tmp_field_int() and reusing it in Item::create_tmp_field()
         and Item_func_signed::create_tmp_field().
         Fixing the code in Item::create_tmp_field_int() to call
         Type_handler::make_table_field() instead of doing "new Field_long[long]"
         directly. This change revealed a problem reported in MDEV-12862.
      
      2. Changing the "long vs longlong" cut-off length for
           - Item_func::create_tmp_field()
           - Item_sum::create_tmp_field()
           - Item_func_get_user_var::create_tmp_field()
         from MY_INT32_NUM_DECIMAL_DIGITS to (MY_INT32_NUM_DECIMAL_DIGITS - 2).
         This fixes MDEV-12858.
         After this change, the "convert_int_length" parameter to
         Item::create_tmp_field() is not needed any more, because
         (MY_INT32_NUM_DECIMAL_DIGITS - 2) is always passed.
         So removing the "convert_int_length" parameter.
      
      3. Fixing Item::create_tmp_field() to pass max_char_length() instead
         of max_length to the constructor of Field_double().
         This fixes MDEV-12862.
      
      4. Additionally, fixing
         - Type_handler_{tiny|short|int24|long|longlong}::make_table_field()
         - Type_handler_{float|double}::make_table_field()
         to pass max_char_length() instead of max_length to Field contructors.
         This is needed by the change (1).
      
      5. Adding new tests, and recording new correct results in the old tests in:
         - mysql-test/r/type_ranges.result
         - storage/tokudb/mysql-test/tokudb/r/type_ranges.result
      c84bbeda
    • Alexander Barkov's avatar
      MDEV-12860 Out-of-range error on CREATE..SELECT with a view using MAX and... · feb15f4e
      Alexander Barkov authored
      MDEV-12860 Out-of-range error on CREATE..SELECT with a view using MAX and EXTRACT(MINUTE_MICROSECOND..)
      feb15f4e
  10. 21 May, 2017 1 commit
  11. 20 May, 2017 1 commit
  12. 19 May, 2017 2 commits
  13. 18 May, 2017 2 commits
  14. 17 May, 2017 3 commits