summaryrefslogtreecommitdiff
path: root/storage
Commit message (Collapse)AuthorAgeFilesLines
* For the error code ER_TOO_LONG_IDENT, the identifier is expected in the ↵Annamalai Gurusami2013-02-141-1/+0
| | | | my_error call. So removing this line from here.
* Bug #11753153 INNODB GENERATES SYMBOLS THAT ARE TOO LONG, INVALID DDLAnnamalai Gurusami2013-02-1210-2/+159
| | | | | | | | | | | | | | | | FROM SHOW CREATE Problem: The length of the internally generated foreign key name is not checked. Solution: The length of the internally generated foreign key name is checked. If it is greater than the allowed limit, an error message is reported. Also, the constraint name is printed in the same manner as the table name, using the system charset information. rb://1969 approved by Marko.
* Add missing linkage specifiers, so that ha_innodb_plugin.soMarko Mäkelä2013-02-082-1/+2
| | | | will not export internal symbols.
* Bug#16292043 RACE CONDITION IN SRV_EXPORT_INNODB_STATUS() WHEN ACCESSING ↵Marko Mäkelä2013-02-082-30/+52
| | | | | | | | | PURGE_SYS->VIEW srv_export_innodb_status(): Read the purge_sys fields while holding purge_sys->latch. Approved by Sunny Bains
* - BUG#1608883: KILLING A QUERY INSIDE INNODB CAUSES IT TO EVENTUALLY CRASHKrunal Bauskar krunal.bauskar@oracle.com2013-01-301-0/+5
| | | | | | | | | | | | | | | | | | | WITH AN ASSERTION Correcting the build failure that was caused because of changes checked-in to below mentioned revision. (Changes: DEBUG_SYNC_C should be disabled for innodb_plugin under Windows enviornment. Note: only for innodb_plugin.) revno: 3915 revision-id: krunal.bauskar@oracle.com-20130114051951-ang92lkirop37431 parent: nisha.gopalakrishnan@oracle.com-20130112054337-gk5pmzf30d2imuw7 committer: Krunal Bauskar krunal.bauskar@oracle.com branch nick: mysql-5.1 timestamp: Mon 2013-01-14 10:49:51 +0530
* Bug #16089381 : POSSIBLE NUMBER UNDERFLOW AROUND CALLING PAGE_ZIP_EMPTY_SIZE()Yasufumi Kinoshita2013-01-233-23/+37
| | | | | | | some callers for page_zip_empty_size() ignored possibility its returning 0, and could cause underflow. rb#1837 approved by Marko
* Bug#16067973 DROP TABLE SLOW WHEN IT DECOMPRESS COMPRESSED-ONLY PAGESMarko Mäkelä2013-01-213-3/+77
| | | | | | | | | | | | | | | buf_page_get_gen(): Do not attempt to decompress a compressed-only page when mode == BUF_PEEK_IF_IN_POOL. This mode is only being used by btr_search_drop_page_hash_when_freed(). There cannot be any adaptive hash index pointing to a page that does not exist in uncompressed format in the buffer pool. innodb_buffer_pool_evict_update(): New function for debug builds, to handle SET GLOBAL innodb_buffer_pool_evicted='uncompressed' by evicting all uncompressed page frames of compressed tablespaces from the buffer pool. rb#1873 approved by Jimmy Yang
* Bug#11758009 - UNION EXECUTION ORDER WRONG ?Neeraj Bisht2013-01-151-5/+8
| | | | | | | | | | | | | | | | | | | | | | Problem:- In case of blob data field, UNION ALL doesn't give correct result. Analysis:- In MyISAM table, when we dont want to check for the distinct for particular key, we set the key_map to zero. While writing record in MyISAM table, we check the distinct with the help of keys, by checking whether that key is active in key_map and then writing the record. In case of blob field, we are checking for distinct by unique constraint, where we are not checking whether that unique key is active or not in key_map. Solution:- Before checking for distinct, check whether any key is active in key_map. storage/myisam/mi_write.c: check whether key_map is active before checking distinct.
* - BUG#1608883: KILLING A QUERY INSIDE INNODB CAUSES IT TO EVENTUALLY CRASHKrunal Bauskar krunal.bauskar@oracle.com2013-01-143-1/+14
| | | | | | | | | | | | | | | | WITH AN ASSERTION Recently we added check to handle kill query signal for long operating queries. While the query interruption is reported it must to ensure cursor is restore to proper state for HANDLER interface to work correctly. Normal select query will not face this problem, as on recieving interrupt, select query is aborted and new select query result in re-initialization (including cursor). rb://1836. Approved by Marko.
* Bug#13997024 SEGV IN SYNC_ARRAY_CELL_PRINT PRINTING OUT LONG SEMAPHORE WAIT DATASunny Bains2013-01-102-0/+8
| | | | | Backport fix from mysql-5.6.
* Post Fix to Bug#14628410 - ASSERTION `! IS_SET()' FAILED INSatya Bodapati2013-01-071-1/+1
| | | | | | | | | | | DIAGNOSTICS_AREA::SET_OK_STATUS Use DBUG_RETURN() instead of return() if DBUG_ENTER() is used in the function. This patch is to fix the Windows pb2 failure on mysql-5.1 Approved by Marko. rb#1792
* Post Fix to Bug#14628410 - ASSERTION `! IS_SET()' FAILED INSatya Bodapati2013-01-041-1/+11
| | | | | | | | | | | | DIAGNOSTICS_AREA::SET_OK_STATUS Test fails on 5.1 valgrind build. This is because of close(-1) system call. Fixed by adding extra checks for valid file descriptor. Approved by Vasil(Calvin). rb#1792
* Fix Bug#16000909 MEMORY LEAK, MYSQL_INPLACE_ALTER_TABLEVasil Dimov2012-12-181-3/+11
| | | | | | | | | | This is a followup to the fix of Bug#14628410 ASSERTION `! IS_SET()' FAILED IN DIAGNOSTICS_AREA::SET_OK_STATUS (satya.bodapati@oracle.com-20121213132316-5joz4phltx9yhjs7) In innobase_mysql_tmpfile(): allocate/open the file after the return(-1); statement.
* Fix Bug#13463493 INNODB PLUGIN WERE CHANGED, BUT STILL USE THEVasil Dimov2012-12-182-11/+13
| | | | | | | | | | | | | | SAME VERSION NUMBER 1.0.17 Now that InnoDB/InnoDB Plugin is no longer separately developed and distributed from the MySQL server it does not need its own version number. Thus use the MySQL version instead. "Removing" the version altogether is not feasible because the config variable 'innodb_version' cannot be removed in GA branches. Reviewed by: Marko (rb#1751)
* Bug#14329288 IS THE CALL TO IBUF_MERGE_OR_DELETE_FOR_PAGE FROMInaam Rana2012-12-142-7/+20
| | | | | | | | | | | BUF_PAGE_GET_GEN REDUNDANT? rb://1711 approved by: Marko Makela When decompressing a compressed page that had already been accessed in the buffer pool, do not attempt to merge buffered changes.
* Bug#14628410 - ASSERTION `! IS_SET()' FAILED IN DIAGNOSTICS_AREA::SET_OK_STATUSSatya Bodapati2012-12-132-5/+28
| | | | | | | | | | | The error code returned from Merge file/Temp file creation functions are ignored. Use the return codes of the row_merge_file_create() and innobase_mysql_tmpfile() to return the error to caller if file creation fails. Approved by Marko. rb#1618
* Bug #14200010 NEWLY CREATED TABLE DOESN'T ALLOW FOR LOOSE INDEX SCANSAnnamalai Gurusami2012-12-111-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | Problem: Before the ALTER TABLE statement, the array dict_index_t::stat_n_diff_key_vals had proper values calculated and updated. But after the ALTER TABLE statement, all the values of this array is 0. Because of this statistics returned by innodb_rec_per_key() is different before and after the ALTER TABLE statement. Running the ANALYZE TABLE command populates the statistics correctly. Solution: After ALTER TABLE statement, set the flag dict_table_t::stat_initialized correctly so that the table statistics will be recalculated properly when the table is next loaded. But note that we still don't choose the loose index scans. This fix only ensures that an ALTER TABLE does not change the optimizer plan. rb://1639 approved by Marko and Jimmy.
* Reverting fix for bug#14329288Inaam Rana2012-11-302-22/+4
| | | | | revid that is being reverted: marko.makela@oracle.com-20121128070024-hb56t41limja8edz
* Bug#59354 : Bug #12659252 : ASSERT !OTHER_LOCK AT LOCK_REC_ADD_TO_QUEUE ↵Yasufumi Kinoshita2012-11-2814-33/+250
| | | | | | | | | DURING A DELETE OPERATION The converted implicit lock should wait for the prior conflicting lock if found. rb://1437 approved by Marko
* Bug#14329288 IS THE CALL TO IBUF_MERGE_OR_DELETE_FOR_PAGE FROMMarko Mäkelä2012-11-282-4/+22
| | | | | | | | | | BUF_PAGE_GET_GEN REDUNDANT? buf_page_get_gen(): When decompressing a compressed page that had already been accessed in the buffer pool, do not attempt to merge buffered changes. rb:1602 approved by Inaam Rana
* Bug #14676249 : ROW_VERS_IMPL_X_LOCKED_LOW() MIGHT HIT ↵Yasufumi Kinoshita2012-11-264-1/+36
| | | | | | | | | | | | | !BPAGE->FILE_PAGE_WAS_FREED ASSERTION trx_undo_prev_version_build() should confirm existence of inherited (not-own) external pages. Bug #14676084 : ROW_UNDO_MOD_UPD_DEL_SEC() DOESN'T NEED UNDO_ROW AND UNDO_EXT INITIALIZED mtr script could hit the assertion error !bpage->file_page_was_freed using this path. So, also fixed rb://1337 approved by Marko Makela.
* Bug#15859402 INNODB_BUFFER_POOL_READ_AHEAD_EVICTED IS INACCURATEInaam Rana2012-11-163-61/+37
| | | | | | | | | | | | | | | | | rb://1546 approved by: Sunny Bains and Marko Makela Our dealing of buf_page_t::access_time flag is inaccurate. * If LRU eviction has not started we don't set the access_time * If LRU eviction is started we set it only if the block is not 'too old'. * Not a correctness issue but we hold buf_pool::mutex when setting the flag This patch fixes this by: * Setting flag unconditionally whenever the first page access happens * Use buf_page_t mutex to protect write to the flag
* Bug#15872736 FAILING ASSERTIONMarko Mäkelä2012-11-151-1/+0
| | | | Remove a bogus debug assertion.
* Bug#15874001 CREATE INDEX ON A UTF8 CHAR COLUMN FAILS WITH ROW_FORMAT=REDUNDANTMarko Mäkelä2012-11-155-145/+251
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | CHAR(n) in ROW_FORMAT=REDUNDANT tables is always fixed-length (n*mbmaxlen bytes), but in the temporary file it is variable-length (n*mbminlen to n*mbmaxlen bytes) for variable-length character sets, such as UTF-8. The temporary file format used during index creation and online ALTER TABLE is based on ROW_FORMAT=COMPACT. Thus, it should use the variable-length encoding even if the base table is in ROW_FORMAT=REDUNDNAT. dtype_get_fixed_size_low(): Replace an assertion-like check with a debug assertion. rec_init_offsets_comp_ordinary(), rec_convert_dtuple_to_rec_comp(): Make this an inline function. Replace 'ulint extra' with 'bool temp'. rec_get_converted_size_comp_prefix_low(): Renamed from rec_get_converted_size_comp_prefix(), and made inline. Add the parameter 'bool temp'. If temp=true, do not add REC_N_NEW_EXTRA_BYTES. rec_get_converted_size_comp_prefix(): Remove the comment about dict_table_is_comp(). This function is only to be called for other than ROW_FORMAT=REDUNDANT records. rec_get_converted_size_temp(): New function for computing temporary file record size. Omit REC_N_NEW_EXTRA_BYTES from the sizes. rec_init_offsets_temp(), rec_convert_dtuple_to_temp(): New functions, for operating on temporary file records. rb:1559 approved by Jimmy Yang
* Bug #14676111 WRONG PAGE_LEVEL WRITTEN FOR UPPER THAN FATHER PAGE AT ↵Yasufumi Kinoshita2012-11-1218-7/+213
| | | | | | | | | | | | | | BTR_LIFT_PAGE_UP() btr_lift_page_up() writes wrong page number (different by -1) for upper than father page. But in almost all of the cases, the father page should be root page, no upper pages. It is very rare path. In addition the leaf page should not be lifted unless the father page is root. Because the branch pages should not become the leaf pages. rb://1336 approved by Marko Makela.
* Bug #14669848 CRASH DURING ALTER MAKES ORIGINAL TABLE INACCESSIBLEAnnamalai Gurusami2012-11-094-5/+74
| | | | | | | | | | | | | | | | | | | | | | | | | When a new primary key is added to an InnoDB table, then the following steps are taken by InnoDB plugin: . let t1 be the original table. . a temporary table t1@00231 will be created by cloning t1. . all data will be copied from t1 to t1@00231. . rename t1 to t1@00232. . rename t1@00231 to t1. . drop t1@00232. The rename and drop operations involve file operations. But file operations cannot be rolled back. So in row_merge_rename_tables(), just after doing data dictionary update and before doing any file operations, generate redo logs for file operations and commit the transaction. This will ensure that any crash after this commit, the table is still recoverable by moving .ibd and .frm files. Manual recovery is required. During recovery, the rename file operation redo logs are processed. Previously this was being ignored. rb://1460 approved by Marko Makela.
* Bug #11759445: CAN'T DELETE ROWS FROM MEMORY TABLE WITH HASH KEY.Venkata Sidagam2012-11-071-4/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Brief description: After insert some rows to MEMORY table with HASH key some rows can't be deleted in one step. Problem Analysis/solution: info->current_ptr will have the information about the current hash pointer from where we can traverse to the list to get all the remaining tuples. In hp_delete_key we are updating info->current_ptr with the last_pos based on the flag parameter(which is the keydef and last index are same). As part of the fix we are making it to zero only when the code flow reaches to the end of the function hp_delete_key() it means that the next record which has to get deleted will be at the starting of the list so, that in the next call to read record(heap_rnext()) will take line number 100 path instead of 102 path, please see the below code in file hp_rnext.c, function heap_rnext(). 99 else if (!info->current_ptr) /* Deleted or first call */ 100 pos= hp_search(info, keyinfo, info->lastkey, 0); 101 else 102 pos= hp_search(info, keyinfo, info->lastkey, 1); with that change the hp_search() will update the info->current_ptr with the record which needs to be deleted. storage/heap/hp_delete.c: In heap_delete_key() function we are making info->current_ptr to 0 if flag is enabled.
* BUG#11754894: MYISAMCHK ERROR HAS INCORRECT REFERENCE Anirudh Mangipudi2012-10-301-1/+8
| | | | | | | | | | | | | | TO 'MYISAM_SORT_BUFFER_SIZE' Problem: 'myisam_sort_buffer_size' is a parameter used by mysqld program only whereas 'sort_buffer_size' is used by mysqld and myisamchk programs. But the error message printed when myisamchk program is run with insufficient buffer size is myisam_sort_buffer_size is too small which may mislead to the server parameter myisam_sort_buffer_size. SOLUTION: A parameter 'myisam_sort_buffer_size' is added as an alias for 'sort_buffer_size' and the 'sort_buffer_size' parameter is marked as deprecated. So myisamchk also has both the parameters with the same role.
* Backport from 5.6: Bug#14769820 ASSERT FLEN == LENMarko Mäkelä2012-10-221-1/+5
| | | | | | | | | | | | | | IN ALTER TABLE ... ADD UNIQUE KEY A bogus debug assertion failure occurred when reporting a duplicate key on a column prefix of a CHAR column. This is a regression from Bug#14729221 IN-PLACE ALTER TABLE REPORTS '' INSTEAD OF REAL DUPLICATE VALUE FOR PREFIX KEYS. The assertion is only present when UNIV_DEBUG is defined (which it is in debug builds starting from MySQL 5.5). It is a case of overasserting. Fix approved by Inaam Rana on IM.
* Bug#14758405: ALTER TABLE: ADDING SERIAL NULL DATATYPE: ASSERTION:Marko Mäkelä2012-10-183-14/+30
| | | | | | | | | | | | | | | LEN <= SIZEOF(ULONGLONG) This bug was caught in the WL#6255 ALTER TABLE...ADD COLUMN in MySQL 5.6, but there is a bug in all InnoDB versions that support auto-increment columns. row_search_autoinc_read_column(): When reading the maximum value of the auto-increment column, and the column only contains NULL values, return 0. This corresponds to the case when the table is empty in row_search_max_autoinc(). rb:1415 approved by Sunny Bains
* Bug #13702112 : WAIT_FOR_READ IS STUCK IN THE 90SYasufumi Kinoshita2012-10-171-3/+4
| | | | | | rb://1334 approved by: Inaam Rana
* Bug#14729221 IN-PLACE ALTER TABLE REPORTS '' INSTEAD OFMarko Mäkelä2012-10-164-7/+42
| | | | | | | REAL DUPLICATE VALUE FOR PREFIX KEYS innobase_rec_to_mysql(): Invoke dict_index_get_nth_col_or_prefix_pos() instead of dict_index_get_nth_col_pos() to find the column.
* bug#14704286Krunal Bauskar krunal.bauskar@oracle.com2012-10-152-1/+10
| | | | | | | | | | | | | | | | | | SECONDARY INDEX UPDATES MAKE CONSISTENT READS DO O(N^2) UNDO PAGE LOOKUPS (honoring kill query while accessing sec_index) If secondary index is being used for select query evaluation and this query is operating with consistent read snapshot it might take good time for secondary index to return back control to mysql as MVCC would kick in. If user issues "kill query <id>" while query is actively accessing secondary index it will not be honored as there is no hook to check for this condition. Added hook for this check. ----- Parallely secondary index taking too long to evaluate for consistent read snapshot case is being examined for performance improvement. WL#6540.
* Fix compilation error in debug mode:Vasil Dimov2012-10-102-28/+26
| | | | | os/os0file.c:1332: error: ISO C90 forbids mixed declarations and code
* Port the test for Bug#14708715 from 5.1/innodb_plugin into 5.1/innodbVasil Dimov2012-10-091-0/+16
| | | | | although the bug does not exist in 5.1/innodb.
* Update the ChangeLog with the fix of Bug#14708715Vasil Dimov2012-10-091-0/+5
|
* Fix Bug#14708715 CREATE TABLE MEMORY LEAK ON DB_OUT_OF_FILE_SPACEVasil Dimov2012-10-092-1/+20
| | | | | | | | | The problem is in the error handling in row_create_table_for_mysql(). In the 'disk full' case we may forget to call dict_mem_table_free() on the table object. Approved by: Marko (rb:1377 and rb:1386)
* Bug#14731482 UPDATE OR DELETE CORRUPTS A RECORD WITH A LONG PRIMARY KEYMarko Mäkelä2012-10-084-8/+42
| | | | | | | | | | | | | We did not allocate enough bits for index->trx_id_offset, causing an UPDATE or DELETE of a table with a PRIMARY KEY longer than 1024 bytes to corrupt the PRIMARY KEY. dict_index_t: Allocate enough bits. dict_index_build_internal_clust(): Check for overflow of index->trx_id_offset. Trip a debug assertion when overflow occurs. rb:1380 approved by Jimmy Yang
* Bug #13249921 ASSERT !BPAGE->FILE_PAGE_WAS_FREED, USUALLY IN Annamalai Gurusami2012-09-287-159/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | TRANSACTION ROLLBACK Description: During the rollback operation, a blob page is removed earlier than desired. Consider following scenario: 1. create table t1(a int primary key,b blob) engine=innodb; 2. insert into t1 values (1,repeat('b',9000)); 3. begin; 4. update t1 set b=concat(b,'b'); 5. update t1 set a=a+1; 6. insert into t1 values (1,repeat('b',9000)); 7. rollback; The update operation in line 5 produces 2 undo log record. The first undo record (TRX_UNDO_DEL_MARK_REC) goes to trx->update_undo and the second undo record (TRX_UNDO_INSERT_REC) goes to trx->insert_undo. During rollback, they are executed out of order. When the undo record TRX_UNDO_DEL_MARK_REC is applied/executed, the blob ownership is also reset. Because of this the blob page is released earlier than desired. This blob page must have been freed only as part of applying/executing the undo record TRX_UNDO_INSERT_REC. This problem can be avoided by executing the undo records in order. This patch will make innodb to execute the undo records in order. rb://1125 approved by Marko.
* Bug#14636528 INNODB CHANGE BUFFERING IS NOT ENTIRELY CRASH-SAFEMarko Mäkelä2012-09-199-31/+86
| | | | | | | | | | | | | | | | | | | | | | | Delete-mark change buffer records when resorting to a pessimistic delete from the change buffer B-tree. Skip delete-marked records in the change buffer merge and when estimating whether an operation can be buffered. Without this fix, we could try to apply the same buffered changes multiple times if the server was killed at the right moment. In MySQL 5.5 and later: ibuf_get_volume_buffered_count_func(): Ignore delete-marked (already processed) records. ibuf_delete_rec(): Add a crash point before optimistic delete. If the optimistic delete fails, flag the record processed before mtr_commit(). ibuf_merge_or_delete_for_page(): Ignore delete-marked (already processed) records. Backport to 5.1: Rename btr_cur_del_unmark_for_ibuf() to btr_cur_set_deleted_flag_for_ibuf() and add a parameter. rb:1307 approved by Jimmy Yang
* Bug#12701488 ASSERT PAGE_ZIP_VALIDATE, UNIV_ZIP_DEBUGMarko Mäkelä2012-09-179-88/+170
| | | | | | | | | | | | | page_zip_validate(), page_zip_validate_low(): Add a parameter for the B-tree index. page_zip_validate_low(): If the page contents does not match, check that the record link chains match. Furthermore, if dict_index_t is passed, check that the records match. (This reduces coverage a bit: if index=NULL, we will ignore differences in record contents, that is, the page payload.) rb:1264 approved by Inaam Rana
* Bug #13453036 ERROR CODE 1118: ROW SIZE TOO LARGE - EVEN Annamalai Gurusami2012-08-312-4/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | THOUGH IT IS NOT. The following error message is misleading because it claims that the BLOB space is not counted. "ERROR 1118 (42000): Row size too large. The maximum row size for the used table type, not counting BLOBs, is 8126. You have to change some columns to TEXT or BLOBs" When the ROW_FORMAT=compact or ROW_FORMAT=REDUNDANT is used, the BLOB prefix is stored inline along with the row. So the above error message is changed as follows depending on the row format used: For ROW_FORMAT=COMPRESSED or ROW_FORMAT=DYNAMIC, the error message is as follows: "ERROR 42000: Row size too large (> 8126). Changing some columns to TEXT or BLOB may help. In current row format, BLOB prefix of 0 bytes is stored inline." For ROW_FORMAT=COMPACT or ROW_FORMAT=REDUNDANT, the error message is as follows: "ERROR 42000: Row size too large (> 8126). Changing some columns to TEXT or BLOB or using ROW_FORMAT=DYNAMIC or ROW_FORMAT=COMPRESSED may help. In current row format, BLOB prefix of 768 bytes is stored inline." rb://1252 approved by Marko Makela
* Bug#14554000 CRASH IN PAGE_REC_GET_NTH_CONST(NTH=0) DURING COMPRESSEDMarko Mäkelä2012-08-304-2/+41
| | | | | | | | | | | | | | | | | | | | | PAGE SPLIT page_rec_get_nth_const(): Map nth==0 to the page infimum. btr_compress(adjust=TRUE): Add a debug assertion for nth>0. The cursor should never be positioned on the page infimum. btr_index_page_validate(): Add test instrumentation for checking the return values of page_rec_get_nth_const() during CHECK TABLE, and for checking that the page directory slot 0 always contains only one record, the predefined page infimum record. page_cur_delete_rec(), page_delete_rec_list_end(): Add debug assertions guarding against accessing the page slot 0. page_copy_rec_list_start(): Clarify a comment about ret_pos==0. rb:1248 approved by Jimmy Yang
* Bug#14547952: DEBUG BUILD FAILS ASSERTION IN RECORDS_IN_RANGE()Marko Mäkelä2012-08-301-1/+0
| | | | | | | | ha_innodb::records_in_range(): Remove a debug assertion that prohibits an open range (full table). The patch by Jorgen Loland only removed the assertion from the built-in InnoDB, not from the InnoDB Plugin.
* Bug#14547952: DEBUG BUILD FAILS ASSERTION IN RECORDS_IN_RANGE()Jorgen Loland2012-08-281-1/+0
| | | | | | | ha_innobase::records_in_range(): Remove a debug assertion that prohibits an open range (full table). This assertion catches unnecessary calls to this method, but such calls are not harming correctness.
* Fix regression from Bug#12845774 OPTIMISTIC INSERT/UPDATE USES WRONGMarko Mäkelä2012-08-212-6/+21
| | | | | | | | | | | | | | | | | HEURISTICS FOR COMPRESSED PAGE SIZE The fix of Bug#12845774 was supposed to skip known-to-fail btr_cur_optimistic_insert() calls. There was only one such call, in btr_cur_pessimistic_update(). All other callers of btr_cur_pessimistic_insert() would release and reacquire the B-tree page latch before attempting the pessimistic insert. This would allow other threads to restructure the B-tree, allowing (and requiring) the insert to succeed as an optimistic (single-page) operation. Failure to attempt an optimistic insert before a pessimistic one would trigger an attempt to split an empty page. rb:1234 approved by Sunny Bains
* Bug#12595091 POSSIBLY INVALID ASSERTION IN BTR_CUR_PESSIMISTIC_UPDATE()Marko Mäkelä2012-08-162-1/+12
| | | | | | | | | | Facebook got a case where the page compresses really well so that btr_cur_optimistic_update() returns DB_UNDERFLOW, but when a record gets updated, the compression rate radically changes so that btr_cur_insert_if_possible() can not insert in place despite reorganizing/recompressing the page, leading to the assertion failing. rb:1220 approved by Sunny Bains
* Bug#12845774 OPTIMISTIC INSERT/UPDATE USES WRONG HEURISTICS FORMarko Mäkelä2012-08-163-20/+26
| | | | | | | | | | | | | | | | | | | | | | | | COMPRESSED PAGE SIZE This was submitted as MySQL Bug 61456 and a patch provided by Facebook. This patch follows the same idea, but instead of adding a parameter to btr_cur_pessimistic_insert(), we simply remove the btr_cur_optimistic_insert() call there and add it to the only caller that needs it. btr_cur_pessimistic_insert(): Do not try btr_cur_optimistic_insert(). btr_insert_on_non_leaf_level_func(): Invoke btr_cur_optimistic_insert() before invoking btr_cur_pessimistic_insert(). btr_cur_pessimistic_update(): Clarify in a comment why it is not necessary to invoke btr_cur_optimistic_insert(). btr_root_raise_and_insert(): Assert that the root page is not empty. This could happen if a pessimistic insert (involving a split or merge) is performed without first attempting an optimistic (intra-page) insert. rb:1219 approved by Sunny Bains
* Bug#13523839 ASSERTION FAILURES ON COMPRESSED INNODB TABLESMarko Mäkelä2012-08-163-13/+28
| | | | | | | | | | | | | btr_cur_optimistic_insert(): Remove a bogus assertion. The insert may fail after reorganizing the page. btr_cur_optimistic_update(): Do not attempt to reorganize compressed pages, because compression may fail after reorganization. page_copy_rec_list_start(): Use page_rec_get_nth() to restore to the ret_pos, which may also be the page infimum. rb:1221
* Bug#14399148 INNODB TABLES UNDER LOAD PRODUCE DUPLICATE COPIES OF ROWSMarko Mäkelä2012-08-094-73/+83
| | | | | | | | | | | | IN QUERIES This bug was caused by an incorrect fix of Bug#13807811 BTR_PCUR_RESTORE_POSITION() CAN SKIP A RECORD There was nothing wrong with btr_pcur_restore_position(), but with the use of it in the table scan during index creation. rb:1206 approved by Jimmy Yang
View Lorry Controller Status