1. 11 Mar, 2012 1 commit
  2. 08 Mar, 2012 4 commits
    • Georgi Kodinov's avatar
    • Georgi Kodinov's avatar
      merge mysql-5.1->mysql-5.1-security · 4b5306fd
      Georgi Kodinov authored
      4b5306fd
    • Georgi Kodinov's avatar
      7ac4179e
    • Marko Mäkelä's avatar
      Bug#13807811 BTR_PCUR_RESTORE_POSITION() CAN SKIP A RECORD · c5511bdf
      Marko Mäkelä authored
      This bug has been there at least since MySQL 4.0.9. (Before 4.0.9, the
      code probably was even more severely broken.)
      
      btr_pcur_restore_position(): When cursor restoration fails, before
      invoking btr_pcur_store_position() move to the previous or next record
      unless cursor->rel_pos==BTR_PCUR_ON or the record was not a user
      record.
      
      This bug can cause skipped records when btr_pcur_store_position() is
      called on the last record of a page. A symptom would be record count
      mismatch in CHECK TABLE, or failure to find a record to delete-mark or
      update or purge. The following operations should be affected by the
      bug:
      
      * row_search_for_mysql(): SELECT, UPDATE, REPLACE, CHECK TABLE,
        (almost anything else than INSERT)
      
      * foreign key CASCADE operations
      
      * row_merge_read_clustered_index(): index creation (since MySQL 5.1
        InnoDB Plugin)
      
      * multi-threaded purge (after MySQL 5.5): not sure, but it might fail
        to purge some records
      
      Not all callers of btr_pcur_restore_position() should be affected.
      Anything that asserts or checks that restoration succeeds is
      unaffected. For example, cursor restoration on the change buffer tree
      should always succeed, because access is being protected by additional
      latches. Likewise, rollback, or any code accesses data dictionary
      tables while holding dict_sys->mutex should be safe.
      
      rb:967 approved by Jimmy Yang
      c5511bdf
  3. 06 Mar, 2012 2 commits
  4. 05 Mar, 2012 2 commits
    • Ramil Kalimullin's avatar
      BUG#12537203 - CRASH WHEN SUBSELECTING GLOBAL VARIABLES IN GEOMETRY FUNCTION ARGUMENTS · 30d32207
      Ramil Kalimullin authored
      A defect in the subquery substitution code may lead to a server crash:
      setting substitution's name should be followed by setting its length
      (to keep them in sync).
      
      
      mysql-test/r/gis.result:
        BUG#12537203 - CRASH WHEN SUBSELECTING GLOBAL VARIABLES IN GEOMETRY FUNCTION ARGUMENTS
          test result.
      mysql-test/t/gis.test:
        BUG#12537203 - CRASH WHEN SUBSELECTING GLOBAL VARIABLES IN GEOMETRY FUNCTION ARGUMENTS
          test case.
      sql/item_subselect.cc:
        BUG#12537203 - CRASH WHEN SUBSELECTING GLOBAL VARIABLES IN GEOMETRY FUNCTION ARGUMENTS
          set substitution's name length as well as the name itself (to keep them in sync).
      30d32207
    • Ramil Kalimullin's avatar
      Fix for BUG#12414917 - ISCLOSED() CRASHES ON 64-BIT BUILDS · 8aea62fa
      Ramil Kalimullin authored
      Problem:      
      lack of incoming geometry data validation may 
      lead to a server crash when ISCLOSED() function called.
      
      Solution:
      necessary incoming data check added.
      
      
      mysql-test/r/gis.result:
        Fix for BUG#12414917 - ISCLOSED() CRASHES ON 64-BIT BUILDS
          test result.
      mysql-test/t/gis.test:
        Fix for BUG#12414917 - ISCLOSED() CRASHES ON 64-BIT BUILDS 
          test case.
      sql/spatial.cc:
        Fix for BUG#12414917 - ISCLOSED() CRASHES ON 64-BIT BUILDS 
          check if a LINESTRING has at least one point as we 
        rely on that further.
      8aea62fa
  5. 01 Mar, 2012 2 commits
  6. 29 Feb, 2012 3 commits
    • Mattias Jonsson's avatar
      merge into mysql-5.1 · 937ee6b7
      Mattias Jonsson authored
      937ee6b7
    • Praveenkumar Hulakund's avatar
      Bug#12601974 - STORED PROCEDURE SQL_MODE=NO_BACKSLASH_ESCAPES IGNORED AND BREAKS REPLICATION · cf2f9780
      Praveenkumar Hulakund authored
      Analysis:
      ========================
      sql_mode "NO_BACKSLASH_ESCAPES": When user want to use backslash as character input,
      instead of escape character in a string literal then sql_mode can be set to 
      "NO_BACKSLASH_ESCAPES". With this mode enabled, backslash becomes an ordinary 
      character like any other. 
      
      SQL_MODE set applies to the current client session. And while creating the stored 
      procedure, MySQL stores the current sql_mode and always executes the stored 
      procedure in sql_mode stored with the Procedure, regardless of the server SQL 
      mode in effect when the routine is invoked.  
      
      In the scenario (for which bug is reported), the routine is created with 
      sql_mode=NO_BACKSLASH_ESCAPES. And routine is executed with the invoker sql_mode
      is "" (NOT SET) by executing statement "call testp('Axel\'s')".
      Since invoker sql_mode is "" (NOT_SET), the '\' in 'Axel\'s'(argument to function)
      is considered as escape character and column "a" (of table "t1") values are 
      updated with "Axel's". The binary log generated for above update operation is as below,
      
        set sql_mode=XXXXXX (for no_backslash_escapes)
        update test.t1 set a= NAME_CONST('var',_latin1'Axel\'s' COLLATE 'latin1_swedish_ci');
      
      While logging stored procedure statements, the local variables (params) used in
      statements are replaced with the NAME_CONST(var_name, var_value) (Internal function) 
      (http://dev.mysql.com/doc/refman/5.6/en/miscellaneous-functions.html#function_name-const)
      
      On slave, these logs are applied. NAME_CONST is parsed to get the variable and its
      value. Since, stored procedure is created with sql_mode="NO_BACKSLASH_ESCAPES", the sql_mode
      is also logged in. So that at slave this sql_mode is set before executing the statements
      of routine.  So at slave, sql_mode is set to "NO_BACKSLASH_ESCAPES" and then while
      parsing NAME_CONST of string variable, '\' is considered as NON ESCAPE character
      and parsing reported error for "'" (as we have only one "'" no backslash). 
      
      At slave, parsing was proper with sql_mode "NO_BACKSLASH_ESCAPES".
      But above error reported while writing bin log, "'" (of Axel's) is escaped with
      "\" character. Actually, all special characters (n, r, ', ", \, 0...) are escaped
      while writing NAME_CONST for string variable(param, local variable) in bin log 
      irrespective of "NO_BACKSLASH_ESCAPES" sql_mode. So, basically, the problem is 
      that logging string parameter does not take into account sql_mode value.
      
      Fix:
      ========================
      So when sql_mode is set to "NO_BACKSLASH_ESCAPES", escaping  characters as 
      (n, r, ', ", \, 0...) should be avoided. To do so, added a check to not to
      escape such characters while writing NAME_CONST for string variables in bin 
      log. 
      And when sql_mode is set to NO_BACKSLASH_ESCAPES, quote character "'" is
      represented as ''.
      http://dev.mysql.com/doc/refman/5.6/en/string-literals.html (There are several 
      ways to include quote characters within a string: )
      
      cf2f9780
    • Praveenkumar Hulakund's avatar
      Bug#12601974 - STORED PROCEDURE SQL_MODE=NO_BACKSLASH_ESCAPES IGNORED AND BREAKS REPLICATION · c22c9270
      Praveenkumar Hulakund authored
      Analysis:
      ========================
      sql_mode "NO_BACKSLASH_ESCAPES": When user want to use backslash as character input,
      instead of escape character in a string literal then sql_mode can be set to 
      "NO_BACKSLASH_ESCAPES". With this mode enabled, backslash becomes an ordinary 
      character like any other. 
      
      SQL_MODE set applies to the current client session. And while creating the stored 
      procedure, MySQL stores the current sql_mode and always executes the stored 
      procedure in sql_mode stored with the Procedure, regardless of the server SQL 
      mode in effect when the routine is invoked.  
      
      In the scenario (for which bug is reported), the routine is created with 
      sql_mode=NO_BACKSLASH_ESCAPES. And routine is executed with the invoker sql_mode
      is "" (NOT SET) by executing statement "call testp('Axel\'s')".
      Since invoker sql_mode is "" (NOT_SET), the '\' in 'Axel\'s'(argument to function)
      is considered as escape character and column "a" (of table "t1") values are 
      updated with "Axel's". The binary log generated for above update operation is as below,
      
        set sql_mode=XXXXXX (for no_backslash_escapes)
        update test.t1 set a= NAME_CONST('var',_latin1'Axel\'s' COLLATE 'latin1_swedish_ci');
      
      While logging stored procedure statements, the local variables (params) used in
      statements are replaced with the NAME_CONST(var_name, var_value) (Internal function) 
      (http://dev.mysql.com/doc/refman/5.6/en/miscellaneous-functions.html#function_name-const)
      
      On slave, these logs are applied. NAME_CONST is parsed to get the variable and its
      value. Since, stored procedure is created with sql_mode="NO_BACKSLASH_ESCAPES", the sql_mode
      is also logged in. So that at slave this sql_mode is set before executing the statements
      of routine.  So at slave, sql_mode is set to "NO_BACKSLASH_ESCAPES" and then while
      parsing NAME_CONST of string variable, '\' is considered as NON ESCAPE character
      and parsing reported error for "'" (as we have only one "'" no backslash). 
      
      At slave, parsing was proper with sql_mode "NO_BACKSLASH_ESCAPES".
      But above error reported while writing bin log, "'" (of Axel's) is escaped with
      "\" character. Actually, all special characters (n, r, ', ", \, 0...) are escaped
      while writing NAME_CONST for string variable(param, local variable) in bin log 
      Airrespective of "NO_BACKSLASH_ESCAPES" sql_mode. So, basically, the problem is 
      that logging string parameter does not take into account sql_mode value.
      
      Fix:
      ========================
      So when sql_mode is set to "NO_BACKSLASH_ESCAPES", escaping  characters as 
      (n, r, ', ", \, 0...) should be avoided. To do so, added a check to not to
      escape such characters while writing NAME_CONST for string variables in bin 
      log. 
      And when sql_mode is set to NO_BACKSLASH_ESCAPES, quote character "'" is
      represented as ''.
      http://dev.mysql.com/doc/refman/5.6/en/string-literals.html (There are several 
      ways to include quote characters within a string: )
      
      
      
      mysql-test/r/sql_mode.result:
        Added test case for Bug#12601974.
      mysql-test/suite/binlog/r/binlog_sql_mode.result:
        Appended result of test cases added for Bug#12601974.
      mysql-test/suite/binlog/t/binlog_sql_mode.test:
        Added test case for Bug#12601974.
      mysql-test/t/sql_mode.test:
        Appended result of test cases added for Bug#12601974.
      c22c9270
  7. 28 Feb, 2012 2 commits
    • Marko Mäkelä's avatar
      Fix a mistake in the Bug#12861864 fix. · e74c9b71
      Marko Mäkelä authored
      row_drop_table_for_mysql(): Really flag the indexes unavailable before
      starting to drop the table.
      e74c9b71
    • Marko Mäkelä's avatar
      Bug#12861864 RACE CONDITION IN BTR_GET_SIZE() AND DROP INDEX/TABLE/DATABASE · 1bd0c9b5
      Marko Mäkelä authored
      also filed as Bug#13146269, Bug#13713178
      
      btr_get_size(): Add mtr_t parameter. Require that the caller S-latches
      index->lock. If index->page==FIL_NULL or the index is to be dropped,
      return ULINT_UNDEFINED to indicate that the statistics are
      unavailable.
      
      dict_update_statistics(): If btr_get_size() returns ULINT_UNDEFINED,
      fake the index cardinality statistics.
      
      dict_index_set_page(): Unused function, remove.
      
      row_drop_table_for_mysql(): Before starting to drop the table, mark
      the indexes unavailable in the data dictionary cache while holding
      index->lock X-latch.
      
      ha_innobase::prepare_drop_index(), ha_innobase::final_drop_index():
      When setting index->to_be_dropped, acquire the index->lock X-latch.
      
      rb:960 approved by Jimmy Yang
      1bd0c9b5
  8. 27 Feb, 2012 1 commit
  9. 24 Feb, 2012 1 commit
    • Chaithra Gopalareddy's avatar
      Bug#13012483:EXPLAIN EXTENDED, PREPARED STATEMENT, CRASH IN · 6a0d03fc
      Chaithra Gopalareddy authored
      CHECK_SIMPLE_EQUALITY
      
      PROBLEM:
      Crash in "check_simple_equality" when using a subquery with "IN" and
      "ALL" in prepare.
      
      ANALYSIS:
      Crash can be reproduced using a simplified query like this one:
      prepare s from "select 1 from g1 where 1 < all (
                      select @:=(1 in (select 1 from g1)) from g1)";
      
      This bug is currently present only on 5.5.and 5.1. Its fixed as part
      of work log(#1110) in 5.6. We are taking one change to fix this
      in 5.5 and 5.1.
      
      Problem seems to be present because we are trying to evaluate "is_null"
      on an argument which is part of a subquery
      (In Item_is_not_null_test::update_used_tables()).
      But the condition to evaluate is only when we do not have a sub query
      present, which means to say that "with_subselect" is not set.
      With respect to the above query, we create an object of type
      "Item_in_optimizer" which by definition is always associated with a
      subquery. While in 5.6 we set "with_subselect" to true for
      "Item_in_optimizer" object, we do not do the same in 5.5. This results in
      the evaluation for "is_null" resulting in a coredump.
      So, we are now setting "with_subselect" to true for "Item_in_optimizer"
      in 5.1 and 5.5.
      
      
      mysql-test/r/func_in.result:
        Result file changes for the test case added
      mysql-test/t/func_in.test:
        Test case added for Bug#13012483
      sql/item_cmpfunc.h:
        Changed Item_in_optimizer::Item_in_optimizer( ) to set "with_subselect"
        to true
      6a0d03fc
  10. 22 Feb, 2012 2 commits
  11. 21 Feb, 2012 4 commits
  12. 20 Feb, 2012 3 commits
    • Mattias Jonsson's avatar
      Bug#11761296: 53775: QUERY ON PARTITIONED TABLE RETURNS CACHED · 74374933
      Mattias Jonsson authored
                                              RESULT FROM PREVIOUS TRANSACTION
      
      The current Query Cache API is not fully compatible with
      the partitioning engine.
      
      There is no good way to implement support for QC due to:
      1) a static callback for ha_partition would need to have access
      to all partition names and call the underlying callback for each
      [sub]partition with the correct name.
      2) pruning would be impossible, even if one used the ulonglong
      engine_data due to if engine_data is changed, the table is
      invalidated by the QC.
      
      So the only viable solution to avoid incorrect data is to not allow
      caching of queries using partitioned tables.
      
      (There are some extra changes, due to removal of \r as line break)
      74374933
    • Karen Langford's avatar
      Raise version number after cloning 5.1.62 · 457af3df
      Karen Langford authored
      457af3df
    • Sunanda Menon's avatar
      Raise version number after cloning 5.0.96 · bd560bb7
      Sunanda Menon authored
      bd560bb7
  13. 19 Feb, 2012 2 commits
    • Tatjana Azundris Nuernberg's avatar
      BUG#13431369 - MAIN.VARIABLES-NOTEMBEDDED CRASHES THE SERVER SPORADICALLY ON WINDOWS · a775a184
      Tatjana Azundris Nuernberg authored
      On shutdown(), Windows can drop traffic still queued for sending even if that
      wasn't specifically requested. As a result, fatal errors (those after
      signaling which the server will drop the connection) were sometimes only
      seen as "connection lost" on the client side, because the server-side
      shutdown() erraneously discarded the correct error message before sending
      it.
      
      If on Windows, we now use the Windows API to access the (non-broken) equivalent
      of shutdown().
      
      Backport from trunk
      
      a775a184
    • Tatjana Azundris Nuernberg's avatar
      BUG 13454045 - 63524: BUG #35396 "ABNORMAL/IMPOSSIBLE/LARGE QUERY_TIME AND LOCK_TIME" HAPPENS A · ede9f4fa
      Tatjana Azundris Nuernberg authored
      If a query's end time is before before its start time, the system clock has been turn back
      (daylight savings time etc.). When the system clock is changed, we can't tell for certain a
      given query was actually slow. We did not protect against logging such a query with a bogus
      execution time (resulting from end_time - start_time being negative), and possibly logging it
      even though it did not really take long to run.
      
      We now have a sanity check in place.
      
      sql/sql_parse.cc:
        Make sure end time is not before start time - otherwise, we can be SURE the system clock
        was changed in between, but not by how much. In other words, when the clock is changed,
        we don't know how long a query ran, and whether it was slow.
      ede9f4fa
  14. 18 Feb, 2012 1 commit
  15. 17 Feb, 2012 5 commits
    • Tatjana Azundris Nuernberg's avatar
      BUG#13431369 - MAIN.VARIABLES-NOTEMBEDDED CRASHES THE SERVER SPORADICALLY ON WINDOWS · b6b47f88
      Tatjana Azundris Nuernberg authored
      On shutdown(), Windows can drop traffic still queued for sending even if that
      wasn't specifically requested. As a result, fatal errors (those after
      signaling which the server will drop the connection) were sometimes only
      seen as "connection lost" on the client side, because the server-side
      shutdown() erraneously discarded the correct error message before sending
      it.
      
      If on Windows, we now use the Windows API to access the (non-broken) equivalent
      of shutdown().
      
      Backport from trunk
      
      include/violite.h:
        export mysql_socket_shutdown(). It lives in vio in the backport.
      sql/mysqld.cc:
        Go through our own shutdown() rather than straight to the POSIX one.
      vio/viosocket.c:
        Define mysql_socket_shutdown(). On UNIXoid systems, it's just a wrapper for shutdown(), but
        on Window, it uses DisconnectEx, which is magic.
      b6b47f88
    • Georgi Kodinov's avatar
      d79058ca
    • Georgi Kodinov's avatar
      merge mysql-5.1->mysql-5.1-security · 38772110
      Georgi Kodinov authored
      38772110
    • Georgi Kodinov's avatar
      merged mysql-5.0->mysql-5.0-security · 2b507ed0
      Georgi Kodinov authored
      2b507ed0
    • Marko Mäkelä's avatar
      Bug#13721257 RACE CONDITION IN UPDATES OR INSERTS OF WIDE RECORDS · f77329ac
      Marko Mäkelä authored
      This bug was originally filed and fixed as Bug#12612184. The original
      fix was buggy, and it was patched by Bug#12704861. Also that patch was
      buggy (potentially breaking crash recovery), and both fixes were
      reverted.
      
      This fix was not ported to the built-in InnoDB of MySQL 5.1, because
      the function signatures of many core functions are different from
      InnoDB Plugin and later versions. The block allocation routines and
      their callers would have to changed so that they handle block
      descriptors instead of page frames.
      
      When a record is updated so that its size grows, non-updated columns
      can be selected for external (off-page) storage. The bug is that the
      initially inserted updated record contains an all-zero BLOB pointer to
      the field that was not updated. Only after the BLOB pages have been
      allocated and written, the valid pointer can be written to the record.
      
      Between the release of the page latch in mtr_commit(mtr) after
      btr_cur_pessimistic_update() and the re-latching of the page in
      btr_pcur_restore_position(), other threads can see the invalid BLOB
      pointer consisting of 20 zero bytes. Moreover, if the system crashes
      at this point, the situation could persist after crash recovery, and
      the contents of the non-updated column would be permanently lost.
      
      The problem is amplified by the ROW_FORMAT=DYNAMIC and
      ROW_FORMAT=COMPRESSED that were introduced in
      innodb_file_format=barracuda in InnoDB Plugin, but the bug does exist
      in all InnoDB versions.
      
      The fix is as follows. After a pessimistic B-tree operation that needs
      to write out off-page columns, allocate the pages for these columns in
      the mini-transaction that performed the B-tree operation (btr_mtr),
      but write the pages in a separate mini-transaction (blob_mtr). Do
      mtr_commit(blob_mtr) before mtr_commit(btr_mtr). A quirk: Do not reuse
      pages that were previously freed in btr_mtr. Only write the off-page
      columns to 'fresh' pages.
      
      In this way, crash recovery will see redo log entries for blob_mtr
      before any redo log entry for btr_mtr. It will apply the BLOB page
      writes to pages that were marked free at that point. If crash recovery
      fails to see all of the btr_mtr redo log, there will be some
      unreachable BLOB data in free pages, but the B-tree will be in a
      consistent state.
      
      btr_page_alloc_low(): Renamed from btr_page_alloc(). Add the parameter
      init_mtr. Return an allocated block, or NULL. If init_mtr!=mtr but
      the page was already X-latched in mtr, do not initialize the page.
      
      btr_page_alloc(): Wrapper for btr_page_alloc_for_ibuf() and
      btr_page_alloc_low().
      
      btr_page_free(): Add a debug assertion that the page was a B-tree page.
      
      btr_lift_page_up(): Return the father block.
      
      btr_compress(), btr_cur_compress_if_useful(): Add the parameter ibool
      adjust, for adjusting the cursor position.
      
      btr_cur_pessimistic_update(): Preserve the cursor position when
      big_rec will be written and the new flag BTR_KEEP_POS_FLAG is defined.
      Remove a duplicate rec_get_offsets() call. Keep the X-latch on
      index->lock when big_rec is needed.
      
      btr_store_big_rec_extern_fields(): Replace update_inplace with
      an operation code, and local_mtr with btr_mtr. When not doing a
      fresh insert and btr_mtr has freed pages, put aside any pages that
      were previously X-latched in btr_mtr, and free the pages after
      writing out all data. The data must be written to 'fresh' pages,
      because btr_mtr will be committed and written to the redo log after
      the BLOB writes have been written to the redo log.
      
      btr_blob_op_is_update(): Check if an operation passed to
      btr_store_big_rec_extern_fields() is an update or insert-by-update.
      
      fseg_alloc_free_page_low(), fsp_alloc_free_page(),
      fseg_alloc_free_extent(), fseg_alloc_free_page_general(): Add the
      parameter init_mtr. Return an allocated block, or NULL. If
      init_mtr!=mtr but the page was already X-latched in mtr, do not
      initialize the page.
      
      xdes_get_descriptor_with_space_hdr(): Assert that the file space
      header is being X-latched.
      
      fsp_alloc_from_free_frag(): Refactored from fsp_alloc_free_page().
      
      fsp_page_create(): New function, for allocating, X-latching and
      potentially initializing a page. If init_mtr!=mtr but the page was
      already X-latched in mtr, do not initialize the page.
      
      fsp_free_page(): Add ut_ad(0) to the error outcomes.
      
      fsp_free_page(), fseg_free_page_low(): Increment mtr->n_freed_pages.
      
      fsp_alloc_seg_inode_page(), fseg_create_general(): Assert that the
      page was not previously X-latched in the mini-transaction. A file
      segment or inode page should never be allocated in the middle of an
      mini-transaction that frees pages, such as btr_cur_pessimistic_delete().
      
      fseg_alloc_free_page_low(): If the hinted page was allocated, skip the
      check if the tablespace should be extended. Return NULL instead of
      FIL_NULL on failure. Remove the flag frag_page_allocated. Instead,
      return directly, because the page would already have been initialized.
      
      fseg_find_free_frag_page_slot() would return ULINT_UNDEFINED on error,
      not FIL_NULL. Correct a bogus assertion.
      
      fseg_alloc_free_page(): Redefine as a wrapper macro around
      fseg_alloc_free_page_general().
      
      buf_block_buf_fix_inc(): Move the definition from the buf0buf.ic to
      buf0buf.h, so that it can be called from other modules.
      
      mtr_t: Add n_freed_pages (number of pages that have been freed).
      
      page_rec_get_nth_const(), page_rec_get_nth(): The inverse function of
      page_rec_get_n_recs_before(), get the nth record of the record
      list. This is faster than iterating the linked list. Refactored from
      page_get_middle_rec().
      
      trx_undo_rec_copy(): Add a debug assertion for the length.
      
      trx_undo_add_page(): Return a block descriptor or NULL instead of a
      page number or FIL_NULL.
      
      trx_undo_report_row_operation(): Add debug assertions.
      
      trx_sys_create_doublewrite_buf(): Assert that each page was not
      previously X-latched.
      
      page_cur_insert_rec_zip_reorg(): Make use of page_rec_get_nth().
      
      row_ins_clust_index_entry_by_modify(): Pass BTR_KEEP_POS_FLAG, so that
      the repositioning of the cursor can be avoided.
      
      row_ins_index_entry_low(): Add DEBUG_SYNC points before and after
      writing off-page columns. If inserting by updating a delete-marked
      record, do not reposition the cursor or commit the mini-transaction
      before writing the off-page columns.
      
      row_build(): Tighten a debug assertion about null BLOB pointers.
      
      row_upd_clust_rec(): Add DEBUG_SYNC points before and after writing
      off-page columns. Do not reposition the cursor or commit the
      mini-transaction before writing the off-page columns.
      
      rb:939 approved by Jimmy Yang
      f77329ac
  16. 16 Feb, 2012 5 commits