mirror/mariadb
1
0
Fork 0
mirror of https://github.com/MariaDB/server.git synced 2025-01-16 20:12:31 +01:00
Code Issues Projects Releases Packages Wiki Activity Actions

Applying InnoDB Plugin 1.0.6 snapshot, Fixes BUG#48469

Browse source 
applied revisions: r6201, r6202, r6207, r6208, r6210

r6202 - port fix for BUG#48469 to plugin

Detailed revision comments:

r6201 | marko | 2009-11-19 14:09:11 +0200 (Thu, 19 Nov 2009) | 2 lines
branches/zip: ha_innobase::add_index(): Clarify the comment
on orphaned tables when creating a primary key.
r6202 | jyang | 2009-11-19 15:01:00 +0200 (Thu, 19 Nov 2009) | 8 lines
branches/zip: Function fseg_free() is no longer defined
in branches/zip. To port fix for bug #48469 to zip,
we can use btr_free_root() which frees the page,
and also does not require mini-transaction.

Approved by Marko.


r6207 | vasil | 2009-11-20 10:19:14 +0200 (Fri, 20 Nov 2009) | 54 lines
branches/zip: Merge r6198:6206 from branches/5.1:

(r6203 was skipped as it is already in branches/zip)

  ------------------------------------------------------------------------
  r6200 | vasil | 2009-11-19 12:14:23 +0200 (Thu, 19 Nov 2009) | 4 lines
  Changed paths:
     M /branches/5.1/btr/btr0btr.c
  
  branches/5.1:
  
  White space fixup - indent under the opening (
  
  ------------------------------------------------------------------------
  r6203 | jyang | 2009-11-19 15:12:22 +0200 (Thu, 19 Nov 2009) | 8 lines
  Changed paths:
     M /branches/5.1/btr/btr0btr.c
  
  branches/5.1: Use btr_free_root() instead of fseg_free() for
  the fix of bug #48469, because fseg_free() is not defined
  in the zip branch. And we could save one mini-trasaction started
  by fseg_free().
  
  Approved by Marko.
  
  
  ------------------------------------------------------------------------
  r6205 | jyang | 2009-11-20 07:55:48 +0200 (Fri, 20 Nov 2009) | 11 lines
  Changed paths:
     M /branches/5.1/handler/ha_innodb.cc
  
  branches/5.1: Add a special case to handle the Duplicated Key error
  and return DB_ERROR instead. This is to avoid a possible SIGSEGV
  by mysql error handling re-entering the storage layer for dup key
  info without proper table handle.
  This is to prevent a server crash when error situation in bug
  #45961 "DDL on partitioned innodb tables leaves data dictionary
  in an inconsistent state" happens.
  
  rb://157 approved by Sunny Bains.
  
  
  ------------------------------------------------------------------------
  r6206 | jyang | 2009-11-20 09:38:43 +0200 (Fri, 20 Nov 2009) | 5 lines
  Changed paths:
     M /branches/5.1/handler/ha_innodb.cc
  
  branches/5.1: Fix a minor code formating issue for 
  the parenthesis iplacement of the if condition in
  rename_table().
  
  
  ------------------------------------------------------------------------

r6208 | vasil | 2009-11-20 10:49:24 +0200 (Fri, 20 Nov 2009) | 4 lines
branches/zip:

Add ChangeLog entry for c6207.

r6210 | vasil | 2009-11-20 23:39:48 +0200 (Fri, 20 Nov 2009) | 3 lines
branches/zip:

Whitespace fixup.
This commit is contained in:
Satya B 2009-11-30 19:12:26 +05:30
parent 699af6da3a
commit 3606e59cfe
5 changed files with 38 additions and 7 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

7
storage/innodb_plugin/ChangeLog
View file

@ -1,3 +1,10 @@
2009-11-20 The InnoDB Team
* handler/ha_innodb.cc:
Add a workaround to prevent a crash due to Bug#45961 DDL on
partitioned innodb tables leaves data dictionary in an inconsistent
state
2009-11-19 The InnoDB Team
* btr/btr0btr.c:

3
storage/innodb_plugin/btr/btr0btr.c
View file

@ -794,8 +794,7 @@ btr_create(
PAGE_HEADER + PAGE_BTR_SEG_LEAF, mtr)) {
/* Not enough space for new segment, free root
segment before return. */
fseg_free(space, page_no,
PAGE_HEADER + PAGE_BTR_SEG_TOP);
btr_free_root(space, zip_size, page_no, mtr);
return(FIL_NULL);
}

24
storage/innodb_plugin/handler/ha_innodb.cc
View file

@ -793,6 +793,12 @@ convert_error_code_to_mysql(
return(-1); /* unspecified error */
case DB_DUPLICATE_KEY:
/* Be cautious with returning this error, since
mysql could re-enter the storage layer to get
duplicated key info, the operation requires a
valid table handle and/or transaction information,
which might not always be available in the error
handling stage. */
return(HA_ERR_FOUND_DUPP_KEY);
case DB_FOREIGN_DUPLICATE_KEY:
@ -6815,6 +6821,24 @@ ha_innobase::rename_table(
innobase_commit_low(trx);
trx_free_for_mysql(trx);
/* Add a special case to handle the Duplicated Key error
and return DB_ERROR instead.
This is to avoid a possible SIGSEGV error from mysql error
handling code. Currently, mysql handles the Duplicated Key
error by re-entering the storage layer and getting dup key
info by calling get_dup_key(). This operation requires a valid
table handle ('row_prebuilt_t' structure) which could no
longer be available in the error handling stage. The suggested
solution is to report a 'table exists' error message (since
the dup key error here is due to an existing table whose name
is the one we are trying to rename to) and return the generic
error code. */
if (error == (int) DB_DUPLICATE_KEY) {
my_error(ER_TABLE_EXISTS_ERROR, MYF(0), to);
error = DB_ERROR;
}
error = convert_error_code_to_mysql(error, 0, NULL);
DBUG_RETURN(error);

9
storage/innodb_plugin/handler/handler0alter.cc
View file

@ -765,10 +765,11 @@ err_exit:
ut_ad(error == DB_SUCCESS);
/* Commit the data dictionary transaction in order to release
the table locks on the system tables. Unfortunately, this
means that if MySQL crashes while creating a new primary key
inside row_merge_build_indexes(), indexed_table will not be
dropped on crash recovery. Thus, it will become orphaned. */
the table locks on the system tables. This means that if
MySQL crashes while creating a new primary key inside
row_merge_build_indexes(), indexed_table will not be dropped
by trx_rollback_active(). It will have to be recovered or
dropped by the database administrator. */
trx_commit_for_mysql(trx);
row_mysql_unlock_data_dictionary(trx);

2
storage/innodb_plugin/trx/trx0i_s.c
View file

@ -60,7 +60,7 @@ Created July 17, 2007 Vasil Dimov
/** @brief The maximum number of chunks to allocate for a table cache.
The rows of a table cache are stored in a set of chunks. When a new
row is added a new chunk is allocated if necessary. Assuming that the
row is added a new chunk is allocated if necessary. Assuming that the
first one is 1024 rows (TABLE_CACHE_INITIAL_ROWSNUM) and each
subsequent is N/2 where N is the number of rows we have allocated till
now, then 39th chunk would accommodate 1677416425 rows and all chunks