List:Commits« Previous MessageNext Message »
From:marko.makela Date:October 4 2011 7:08am
Subject:bzr push into mysql-trunk branch (marko.makela:3472 to 3473) Bug#13056253
View as plain text  
 3473 Marko Mäkelä	2011-10-04
      Bug#13056253 PERSISTENT STATS, ASSERT IN ANALYZE, HEAP == NULL,
      DICT_STATS_SCAN_PAGE()
      
      Sorry, my bad. This was an off-by-one error in my fix of
      Bug #13034962 CRASHES IN ANALYZE, PERSISTENT STATS, OFFSET 65535
      (bzr revision id marko.makela@strippedm2jfmxek)

    modified:
      storage/innobase/dict/dict0stats.c
      storage/innobase/rem/rem0rec.c
 3472 Inaam Rana	2011-10-03
      Bug#11759044 - 51325: DROPPING AN EMPTY INNODB TABLE TAKES A LONG TIME
      WITH LARGE BUFFER POOL
      
      rb://767
      approved by: Marko
      
      When dropping a table (with an .ibd file i.e.: with
      innodb_file_per_table set) we scan entire LRU to invalidate pages from
      that table. This can be painful in case of large buffer pools as we hold
      the buf_pool->mutex for the scan. Note that gravity of the problem does
      not depend on the size of the table. Even with an empty table but a
      large and filled up buffer pool we'll end up scanning a very long LRU
      list.
      
      The fix is to scan flush_list and just remove the blocks belonging to
      the table from the flush_list, marking them as non-dirty. The blocks
      are left in the LRU list for eventual eviction due to aging. The
      flush_list is typically much smaller than the LRU list but for cases
      where it is very long we have the solution of releasing the
      buf_pool->mutex after scanning 1K pages.
      
      buf_page_[set|unset]_sticky(): Use new IO-state BUF_IO_PIN to ensure
      that a block stays in the flush_list and LRU list when we release
      buf_pool->mutex. Previously we have been abusing BUF_IO_READ to achieve
      this.

    modified:
      storage/innobase/buf/buf0buf.c
      storage/innobase/buf/buf0lru.c
      storage/innobase/handler/i_s.cc
      storage/innobase/include/buf0buf.h
      storage/innobase/include/buf0buf.ic
      storage/innobase/include/buf0types.h
=== modified file 'storage/innobase/dict/dict0stats.c'
--- a/storage/innobase/dict/dict0stats.c	revid:inaam.rana@stripped
+++ b/storage/innobase/dict/dict0stats.c	revid:marko.makela@oracle.com-20111004070634-6kajpldmc1t5414d
@@ -791,8 +791,12 @@ dict_stats_analyze_index_below_cur(
 	/* Allocate offsets for the record and the node pointer, for
 	node pointer records. In a secondary index, the node pointer
 	record will consist of all index fields followed by a child
-	page number. */
-	size = REC_OFFS_HEADER_SIZE + 1 + dict_index_get_n_fields(index);
+	page number.
+	Allocate space for the offsets header (the allocation size at
+	offsets[0] and the REC_OFFS_HEADER_SIZE bytes), and n_fields + 1,
+	so that this will never be less than the size calculated in
+	rec_get_offsets_func(). */
+	size = (1 + REC_OFFS_HEADER_SIZE) + 1 + dict_index_get_n_fields(index);
 
 	heap = mem_heap_create(size * (sizeof *offsets1 + sizeof *offsets2));
 	offsets1 = mem_heap_alloc(heap, size * sizeof *offsets1);

=== modified file 'storage/innobase/rem/rem0rec.c'
--- a/storage/innobase/rem/rem0rec.c	revid:inaam.rana@stripped
+++ b/storage/innobase/rem/rem0rec.c	revid:marko.makela@oracle.com-20111004070634-6kajpldmc1t5414d
@@ -550,6 +550,9 @@ rec_get_offsets_func(
 			n = dict_index_get_n_fields(index);
 			break;
 		case REC_STATUS_NODE_PTR:
+			/* Node pointer records consist of the
+			uniquely identifying fields of the record
+			followed by a child page number field. */
 			n = dict_index_get_n_unique_in_tree(index) + 1;
 			break;
 		case REC_STATUS_INFIMUM:
@@ -569,6 +572,8 @@ rec_get_offsets_func(
 		n = n_fields;
 	}
 
+	/* The offsets header consists of the allocation size at
+	offsets[0] and the REC_OFFS_HEADER_SIZE bytes. */
 	size = n + (1 + REC_OFFS_HEADER_SIZE);
 
 	if (UNIV_UNLIKELY(!offsets)

No bundle (reason: useless for push emails).
Thread
bzr push into mysql-trunk branch (marko.makela:3472 to 3473) Bug#13056253marko.makela5 Oct