1. 12 Feb, 2018 3 commits
  2. 10 Feb, 2018 2 commits
  3. 08 Feb, 2018 8 commits
    • Marko Mäkelä's avatar
      MDEV-14663 Assertion page_is_root(block->frame) failed in innobase_add_instant_try · e3cf5779
      Marko Mäkelä authored
      innobase_add_instant_try(): If the leftmost leaf page does not contain
      other records than the 'default row', only empty the table if there
      are no successor pages.
      
      When a table or partition which was not empty during a previous
      instant ADD COLUMN became empty later, and now with this subsequent
      instant ADD COLUMN we have the opportunity to convert the empty table
      or partition to 'non-instant' format.
      
      Similarly, if the table or partition is empty to begin with, that is,
      it does not even contain a 'default row' record, we can use the
      'non-instant' format.
      e3cf5779
    • Marko Mäkelä's avatar
      Add page_has_prev(), page_has_next(), page_has_siblings() · 32170f8c
      Marko Mäkelä authored
      Until now, InnoDB inefficiently compared the aligned fields
      FIL_PAGE_PREV, FIL_PAGE_NEXT to the byte-order-agnostic value FIL_NULL.
      32170f8c
    • Jan Lindström's avatar
      MDEV-14427: encryption.innodb-bad-key-change failed in buildbot · 3969d97e
      Jan Lindström authored
      Timing problem as sometimes table is marked as encrypted but
      sometimes we are not sure and table is just marked missing.
      3969d97e
    • Vladislav Vaintroub's avatar
      Innodb, Windows : Reenable compiler optimizations for mem0mem.cc · 627d33d9
      Vladislav Vaintroub authored
      Compiler optimizations were switched off due to
      MySQL Bug #19424, #36366, #34297, due to an alleged compiler bug.
      No  proper analysis of code generation was done back then, thus proof of
      a compiler bug is missing.
      
      Even if there was a compiler bug 13 years ago, it could have been fixed.
      Will wait and see if there are any complains or crashes
      627d33d9
    • Vladislav Vaintroub's avatar
      6c5d3649
    • Marko Mäkelä's avatar
      Revert an accidental change · bbdb47ff
      Marko Mäkelä authored
      trx_undo_rec_copy(): Use a debug assertion. In a non-debug build,
      with len<0 (which this assertion is really testing for)
      we should still typically crash due to running out of memory.
      bbdb47ff
    • Marko Mäkelä's avatar
      Remove dict_table_t::is_clust() · 7660d8c9
      Marko Mäkelä authored
      Replace all occurrences of the is_clust() method with is_primary(),
      because that is what is actually meant. (Also the change buffer
      tree would count as a clustered index.)
      7660d8c9
    • Marko Mäkelä's avatar
      MDEV-14407 Assertion failure during rollback · 609d0a91
      Marko Mäkelä authored
      Rollback attempted to dereference DB_ROLL_PTR=0, which cannot possibly
      be a valid undo log pointer. A safer canonical value would be
      roll_ptr_t(1) << ROLL_PTR_INSERT_FLAG_POS
      which is what was chosen in MDEV-12288, corresponding to reset_trx_id.
      
      No deterministic test case for the bug was found. The simplest test
      cases may be related to MDEV-11415, which suppresses undo logging for
      ALGORITHM=COPY operations. In those operations, in the spirit of
      MDEV-12288, we should actually have written reset_trx_id instead of
      using the transaction identifier of the current transaction
      (and a bogus value of DB_ROLL_PTR=0). However, thanks to MySQL Bug#28432
      which I had fixed in MySQL 5.6.8 as part of WL#6255, access to the
      rebuilt table by earlier-started transactions should actually have been
      refused with ER_TABLE_DEF_CHANGED.
      
      reset_trx_id: Move the definition to data0type.cc and the declaration
      to data0type.h.
      
      btr_cur_ins_lock_and_undo(): When undo logging is disabled, use the
      safe value that corresponds to reset_trx_id.
      
      btr_cur_optimistic_insert(): Validate the DB_TRX_ID,DB_ROLL_PTR before
      inserting into a clustered index leaf page.
      
      ins_node_t::sys_buf[]: Replaces row_id_buf and trx_id_buf and some
      heap usage.
      
      row_ins_alloc_sys_fields(): Init ins_node_t::sys_buf[] to reset_trx_id.
      
      row_ins_buf(): Only if undo logging is enabled, copy trx->id
      to node->sys_buf. Otherwise, rely on the initialization in
      row_ins_alloc_sys_fields().
      
      row_purge_reset_trx_id(): Invoke mlog_write_string() with reset_trx_id
      directly. (No functional change.)
      
      trx_undo_page_report_modify(): Assert that the DB_ROLL_PTR is not 0.
      
      trx_undo_get_undo_rec_low(): Assert that the roll_ptr is valid before
      trying to dereference it.
      
      dict_index_t::is_primary(): Check if the index is the primary key.
      
      PageConverter::adjust_cluster_record(): Fix
      MDEV-15249 Crash in MVCC read after IMPORT TABLESPACE
      by resetting the system fields to reset_trx_id instead of writing
      the current transaction ID (which will be committed at the
      end of the IMPORT TABLESPACE) and DB_ROLL_PTR=0.
      This can partially be viewed as a follow-up fix of MDEV-12288,
      because IMPORT should already then have written
      DB_TRX_ID=0 and DB_ROLL_PTR=1<<55 to prevent unnecessary
      DB_TRX_ID lookups in subsequent accesses to the table.
      609d0a91
  4. 07 Feb, 2018 8 commits
  5. 06 Feb, 2018 7 commits
  6. 05 Feb, 2018 2 commits
  7. 04 Feb, 2018 4 commits
    • Alexander Barkov's avatar
      d67dcb7b
    • Alexander Barkov's avatar
    • Alexander Barkov's avatar
      MDEV-15176 Storing DATETIME-alike VARCHAR data into TIME produces wrong results · 28d4cf0c
      Alexander Barkov authored
      When storing '0001-01-01 10:20:30x', execution went throw the last code
      branch in Field_time::store_TIME_with_warning(), around the test
      for (ltime->year || ltime->month). This then resulted into wrong results
      because:
      
      1. Field_time::store_TIME() does not check YYYYMM against zero.
        It assumes that ltime->days and ltime->hours are already properly set.
        So it mixed days to hours, even when YYYYMM was not zero.
      
      2. Field_time_hires::store_TIME() does not check YYYYMM against zero.
        It assumes that ltime->year, ltime->month, ltime->days and ltime->hours
        are already properly set. So it always mixed days and even months(!) and years(!)
        to hours, using pack_time(). This gave even worse results comparing to #2.
      
      3. Field_timef::store_TIME() did not check the entire YYYYMM for being zero.
        It only checked MM, but did not check YYYY. In case of a zero MM,
        it mixed days to hours, even if YYYY was not zero.
        The wrong code was in TIME_to_longlong_time_packed().
      
      In the new reduction Field_time::store_TIME_with_warning() is responsible
      to prepare the YYYYYMMDD part properly in all code branches
      (with trailing garbage like 'x' and without trailing garbage).
      It was reorganized into a more straightforward style.
      
      Field_time:store_TIME(), Field_time_hires::store_TIME() and
      TIME_to_longlong_time_packed() were fixed to do a DBUG_ASSERT
      on non-zero ltime->year or ltime->month. The code testing ltime->month
      was removed from TIME_to_longlong_time_packed(), as it's now
      properly done on the caller level.
      
      Truncation was moved from Field_timef::store_TIME() to
      Field_time::store_TIME_with_warning().
      
      So now all thee methods Field_time*::store_TIME() assume a properly
      set input value:
      - Only zero ltime->year and ltime->month are allowed.
      - The value must be already properly truncated according to decimals()
        (this will help to add rounding soon, see MDEV-8894)
      
      A "const" qualifier was added to the argument of Field_time*::store_TIME().
      28d4cf0c
    • Marko Mäkelä's avatar
      Clarify a comment after MDEV-15061 · d6ed077f
      Marko Mäkelä authored
      d6ed077f
  8. 03 Feb, 2018 1 commit
  9. 02 Feb, 2018 5 commits
    • Alexander Barkov's avatar
      Setting Field::field_index for Virtual_tmp_table fields · 705283f7
      Alexander Barkov authored
      Virtial_tmp_table did not set the "field_index" member for its Fields.
      Fixing Virtual_tmp_table::add() to set "field_index" to the Field's ordinal position
      inside the table, like a normal TABLE does, for consistency.
      
      Although, this flaw did not seem to cause any bugs, having field_index properly
      set is helpful for debugging purposes.
      705283f7
    • Sachin Setiya's avatar
      This commit solves a couple of issues · c8299e62
      Sachin Setiya authored
      1st. Create_field does not have function vers_sys_field() kind of handy
      function, second I think Create_field and Field should not divert much , and
      Field does have this function.
      
      2nd. Versioning column does not have NOT_NULL_FLAG, since they can never be
      null. So I have added NOT_NULL_FLAG.
      
      3rd. Since I added NOT_NULL_FLAG this created one issue , versioning column
      of datatype bigint unsigned were getting NO_DEFAULT_VALUE_FLAG. This makes
      test like versioning.insert to fail, Reason being If a column gets this
      flag if we insert 'default' value it will generate error(that is why ) test
      was failing. So now versioning column wont get NO_DEFAULT_VALUE_FLAG flag.
      c8299e62
    • Sachin Setiya's avatar
      MDEV-14849 CREATE + ALTER with user-invisible columns produce ... · 16be7469
      Sachin Setiya authored
      Problem:-
        create or replace table t1 (pk int auto_increment primary key invisible, i int);
        alter table t1 modify pk int invisible;
       This last alter makes a invisible column which is not null and does not
       have default value.
      
      Analysis:-
       This is caused because our error check for NOT_NULL_FLAG and
       NO_DEFAULT_VALUE_FLAG flag misses this sql_field , but this is not the fault
       of error check :).Actually this field come via mysql_prepare_alter_table
       and it does not have NO_DEFAULT_VALUE_FLAG flag turned on. (If it was create
       table NO_DEFAULT_VALUE_FLAG would have turned on Column_definition::check)
       and this would have generated error.
      
      Solution:-
       I have moved the error check to kind last of mysql_prepare_create_table
       because upto this point we have applied NO_DEFAULT_VALUE_FLAG to required
       column.
      16be7469
    • Sachin Setiya's avatar
      Mdev-15085 Invisible Column Non-constant Default value results... · 2d73b581
      Sachin Setiya authored
      Problem:- If we create table field with dynamic default value then that
       field always gets NULL value.
      
      Analyze:- This is because in fill_record we simple continue at Invisible
       column because we though that share->default_values(default value is
       always copied into table->record[0] before insert) will have a default
       value for them(which is true for constant defaults , but not for dynamic
       defaults).
      
      Solution:- We simple set all_fields_have_value to null , and this will
      make call to update_default_fields (in the case of dynamic default), And
      default expr will be evaluted and value will be set in field.
      2d73b581
    • Monty's avatar
      Added name to MEM_ROOT for esier debugging · d69642de
      Monty authored
      This will make it easier to how memory allocation is done when debugging
      with either DBUG or gdb.
      
      Will especially help when debugging stored procedures
      
      Main change is a name argument as second argument to init_alloc_root()
      init_sql_alloc()
      
      Other things:
      - Added DBUG_ENTER/EXIT to some Virtual_tmp_table functions
      d69642de