1. 12 Feb, 2018 6 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 2 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