mariadb

Commit Graph

Author	SHA1	Message	Date
Annamalai Gurusami	22b3830483	Bug #13117023 : Innodb increments handler_read_key when it should not The counter handler_read_key (SSV::ha_read_key_count) is incremented incorrectly. The mysql server maintains a per thread system_status_var (SSV) object. This object contains among other things the counter SSV::ha_read_key_count. The purpose of this counter is to measure the number of requests to read a row based on a key (or the number of index lookups). This counter was wrongly incremented in the ha_innobase::innobase_get_index(). The fix removes this increment statement (for both innodb and innodb_plugin). The various callers of the innobase_get_index() was checked to determine if anybody must increment this counter (if they first call innobase_get_index() and then perform an index lookup). It was found that no caller of innobase_get_index() needs to worry about the SSV::ha_read_key_count counter.	14 years ago
Marko Mäkelä	dcab3c9393	Bug #12842206 INNODB LOCKING REGRESSION FOR INSERT IGNORE: Add a test case. The bug was accidentally fixed by fixing Bug#11759688 52020: InnoDB can still deadlock on just INSERT...ON DUPLICATE KEY a.k.a. the reintroduction of Bug#7975 deadlock without any locking, simple select and update	14 years ago
Marko Mäkelä	d7946a908f	Bug#11759688 52020: InnoDB can still deadlock on just INSERT...ON DUPLICATE KEY a.k.a. Bug#7975 deadlock without any locking, simple select and update Bug#7975 was reintroduced when the storage engine API was made pluggable in MySQL 5.1. Instead of looking at thd->lex directly, we rely on handler::extra(). But, we were looking at the wrong extra() flag, and we were ignoring the TRX_DUP_REPLACE flag in places where we should obey it. innodb_replace.test: Add tests for hopefully all affected statement types, so that bug should never ever resurface. This kind of tests should have been added when fixing Bug#7975 in MySQL 5.0.3 in the first place. rb:806 approved by Sunny Bains	14 years ago
Marko Mäkelä	825f88634b	Fix results after Bug#12661768 fix.	14 years ago
Marko Mäkelä	579234694f	Bug#13002783 PARTIALLY UNINITIALIZED CASCADE UPDATE VECTOR In the ON UPDATE CASCADE clause of FOREIGN KEY constraints, the calculated update vector was not fully initialized. This bug was introduced in the InnoDB Plugin when implementing support for ROW_FORMAT=DYNAMIC. Additionally, the data type information was not initialized, but apparently it has never been needed in this case. Nevertheless, it is not good programming practice to pass uninitialized values around. calc_row_difference(): Declare the update field uninitialized in Valgrind. Copy the data type information as well, except when the field is SQL NULL. In the built-in InnoDB, initialize ufield->extern_storage = FALSE (an initialization bug that had gone unnoticed this far). The InnoDB Plugin and later have this flag to dfield_t and have always initialized it properly. row_ins_cascade_calc_update_vec(): Reduce the scope of some pointers. Initialize orig_len. (This caused the bug in InnoDB Plugin and later.) row_ins_foreign_check_on_constraint(): Simplify a condition. Declare the update vector uninitialized. rb:771 approved by Jimmy Yang	14 years ago
Vasil Dimov	7312f83cb9	Fix Bug#12661768 UPDATE IGNORE CRASHES SERVER IF TABLE IS INNODB AND IT IS PARENT FOR OTHER ONE Do not try to lookup key_nr'th key in 'table' because there may not be such a key there. key_nr is the number of the key in the _child_ table name, not in the parent table. Instead just print the fields of the record that are covered by the first key defined on the parent table. This bug gets a better fix in MySQL 5.6, which is too risky for 5.1 and 5.5. Approved by: Jon Olav Hauglid (via IM)	14 years ago
Dmitry Lenev	d076be2a32	Fix for bug #11762012 - "54553: INNODB ASSERTS IN HA_INNOBASE::UPDATE_ROW, TEMPORARY TABLE, TABLE LOCK". Attempt to update an InnoDB temporary table under LOCK TABLES led to assertion failure in both debug and production builds if this temporary table was explicitly locked for READ. The same scenario works fine for MyISAM temporary tables. The assertion failure was caused by discrepancy between lock that was requested on the rows of temporary table at LOCK TABLES time and by update operation. Since SQL-layer requested a read-lock at LOCK TABLES time InnoDB engine assumed that upcoming statements which are going to be executed under LOCK TABLES will only read table and therefore should acquire only S-lock. An update operation broken this assumption by requesting X-lock. Possible approaches to fixing this problem are: 1) Skip locking of temporary tables as locking doesn't make any sense for connection-local objects. 2) Prohibit changing of temporary table locked by LOCK TABLES ... READ. Unfortunately both of these approaches have drawbacks which make them unviable for stable versions of server. So this patch takes another approach and changes code in such way that LOCK TABLES for a temporary table will always request write lock. In 5.1 version of this patch switch from read lock to write lock is done inside of InnoDBs handler methods as doing it on SQL-layer causes compatibility troubles with FLUSH TABLES WITH READ LOCK.	15 years ago
Marko Mäkelä	1a0dde9206	Bug #11766513 - 59641: Prepared XA transaction in system after hard crash causes future shutdown hang InnoDB would hang on shutdown if any XA transactions exist in the system in the PREPARED state. This has been masked by the fact that MySQL would roll back any PREPARED transaction on shutdown, in the spirit of Bug #12161 Xa recovery and client disconnection. [mysql-test-run] do_shutdown_server: Interpret --shutdown_server 0 as a request to kill the server immediately without initiating a shutdown procedure. xid_cache_insert(): Initialize XID_STATE::rm_error in order to avoid a bogus error message on XA ROLLBACK of a recovered PREPARED transaction. innobase_commit_by_xid(), innobase_rollback_by_xid(): Free the InnoDB transaction object after rolling back a PREPARED transaction. trx_get_trx_by_xid(): Only consider transactions whose trx->is_prepared flag is set. The MySQL layer seems to prevent attempts to roll back connected transactions that are in the PREPARED state from another connection, but it is better to play it safe. The is_prepared flag was introduced in the InnoDB Plugin. trx_n_prepared: A new counter, counting the number of InnoDB transactions in the PREPARED state. logs_empty_and_mark_files_at_shutdown(): On shutdown, allow trx_n_prepared transactions to exist in the system. trx_undo_free_prepared(), trx_free_prepared(): New functions, to free the memory objects of PREPARED transactions on shutdown. This is not needed in the built-in InnoDB, because it would collect all allocated memory on shutdown. The InnoDB Plugin needs this because of innodb_use_sys_malloc. trx_sys_close(): Invoke trx_free_prepared() on all remaining transactions.	15 years ago
Vasil Dimov	619f684f54	Add the testcase for Bug#59410 to 5.1/builtin Bug#59410 read uncommitted: unlock row could not find a 3 mode lock on the record This bug is present only in 5.6 but I am adding the test case to earlier versions to ensure it never appears in earlier versions too.	15 years ago
Bjorn Munch	aa4bfebaee	Bug #11762804 55442: MYSQLD DEBUG CRASHES WHILE RUNNING MYISAM_CRASH_BEFORE_FLUSH_KEYS.TEST This will cause affected tests to skip if CrashReporter would popup Found 5 tests that needed modification	15 years ago
Marko Mäkelä	db55cf8526	Allow 30 seconds for slow shutdown in the Bug #60049 test.	15 years ago
Marko Mäkelä	e428f0ed9d	Disable the Bug #60049 test on embedded, as it requires server restart.	15 years ago
Marko Mäkelä	afda842f02	Make the implicit unpack parameter explicit in the Bug #60049 test.	15 years ago
Marko Mäkelä	518a4440ea	Add a test for suspected Bug#60049.	15 years ago
MySQL Build Team	0b054706d9	Backport into build-201102032246-5.1.52sp1 > ------------------------------------------------------------ > revno: 3520 > revision-id: sergey.glukhov@oracle.com-20101214093303-wmo9mqcb8rz0wv9f > parent: tor.didriksen@oracle.com-20101213161301-81lprlbune7r98dl > committer: Sergey Glukhov <sergey.glukhov@oracle.com> > branch nick: mysql-5.1-bugteam > timestamp: Tue 2010-12-14 12:33:03 +0300 > message: > Fixed following problems: > --Bug#52157 various crashes and assertions with multi-table update, stored function > --Bug#54475 improper error handling causes cascading crashing failures in innodb/ndb > --Bug#57703 create view cause Assertion failed: 0, file .\item_subselect.cc, line 846 > --Bug#57352 valgrind warnings when creating view > --Recently discovered problem when a nested materialized derived table is used > before being populated and it leads to incorrect result > > We have several modes when we should disable subquery evaluation. > The reasons for disabling are different. It could be > uselessness of the evaluation as in case of 'CREATE VIEW' > or 'PREPARE stmt', or we should disable subquery evaluation > if tables are not locked yet as it happens in bug#54475, or > too early evaluation of subqueries can lead to wrong result > as it happened in Bug#19077. > Main problem is that if subquery items are treated as const > they are evaluated in ::fix_fields(), ::fix_length_and_dec() > of the parental items as a lot of these methods have > Item::val_...() calls inside. > We have to make subqueries non-const to prevent unnecessary > subquery evaluation. At the moment we have different methods > for this. Here is a list of these modes: > > 1. PREPARE stmt; > We use UNCACHEABLE_PREPARE flag. > It is set during parsing in sql_parse.cc, mysql_new_select() for > each SELECT_LEX object and cleared at the end of PREPARE in > sql_prepare.cc, init_stmt_after_parse(). If this flag is set > subquery becomes non-const and evaluation does not happen. > > 2. CREATE\|ALTER VIEW, SHOW CREATE VIEW, I_S tables which > process FRM files > We use LEX::view_prepare_mode field. We set it before > view preparation and check this flag in > ::fix_fields(), ::fix_length_and_dec(). > Some bugs are fixed using this approach, > some are not(Bug#57352, Bug#57703). The problem here is > that we have a lot of ::fix_fields(), ::fix_length_and_dec() > where we use Item::val_...() calls for const items. > > 3. Derived tables with subquery = wrong result(Bug19077) > The reason of this bug is too early subquery evaluation. > It was fixed by adding Item::with_subselect field > The check of this field in appropriate places prevents > const item evaluation if the item have subquery. > The fix for Bug19077 fixes only the problem with > convert_constant_item() function and does not cover > other places(::fix_fields(), ::fix_length_and_dec() again) > where subqueries could be evaluated. > > Example: > CREATE TABLE t1 (i INT, j BIGINT); > INSERT INTO t1 VALUES (1, 2), (2, 2), (3, 2); > SELECT * FROM (SELECT MIN(i) FROM t1 > WHERE j = SUBSTRING('12', (SELECT * FROM (SELECT MIN(j) FROM t1) t2))) t3; > DROP TABLE t1; > > 4. Derived tables with subquery where subquery > is evaluated before table locking(Bug#54475, Bug#52157) > > Suggested solution is following: > > -Introduce new field LEX::context_analysis_only with the following > possible flags: > #define CONTEXT_ANALYSIS_ONLY_PREPARE 1 > #define CONTEXT_ANALYSIS_ONLY_VIEW 2 > #define CONTEXT_ANALYSIS_ONLY_DERIVED 4 > -Set/clean these flags when we perform > context analysis operation > -Item_subselect::const_item() returns > result depending on LEX::context_analysis_only. > If context_analysis_only is set then we return > FALSE that means that subquery is non-const. > As all subquery types are wrapped by Item_subselect > it allow as to make subquery non-const when > it's necessary.	15 years ago
MySQL Build Team	d27ac61f9d	Backport into build-201102032246-5.1.52sp1 > ------------------------------------------------------------ > revno: 3518 > revision-id: sergey.glukhov@oracle.com-20101213114812-kaq7sh0s623128lv > parent: sergey.glukhov@oracle.com-20101213103926-okypkn10adeeyns8 > committer: Sergey Glukhov <sergey.glukhov@oracle.com> > branch nick: mysql-5.1-bugteam > timestamp: Mon 2010-12-13 14:48:12 +0300 > message: > Bug#39828 : Autoinc wraps around when offset and increment > 1 > Auto increment value wraps when performing a bulk insert with > auto_increment_increment and auto_increment_offset greater than > one. > The fix: > If overflow happened then return MAX_ULONGLONG value as an > indication of overflow and check this before storing the > value into the field in update_auto_increment().	15 years ago
Dmitry Lenev	3473329d3b	Fix for bug #58650 "Failing assertion: primary_key_no == -1 \|\| primary_key_no == 0". Attempt to create InnoDB table with non-nullable column of geometry type having an unique key with length 12 on it and with some other candidate key led to server crash due to assertion failure in both non-debug and debug builds. The problem was that such a non-candidate key could have been sorted as the first key in table/.FRM, before any legit candidate keys. This resulted in assertion failure in InnoDB engine which assumes that primary key should either be the first key in table/.FRM or should not exist at all. The reason behind such an incorrect sorting was an wrong value of Create_field::key_length member for geometry field (which was set to its pack_length == 12) which confused code in mysql_prepare_create_table(), so it would skip marking such key as a key with partial segments. This patch fixes the problem by ensuring that this member gets the same value of Create_field::key_length member as for other blob fields (from which geometry field class is inherited), and as result unique keys on geometry fields are correctly marked as having partial segments.	15 years ago
Jimmy Yang	669ce69483	Fix Bug#30423 "InnoDBs treatment of NULL in index stats causes bad "rows examined" estimates". This change implements "innodb_stats_method" with options of "nulls_equal", "nulls_unequal" and "null_ignored". rb://553 approved by Marko	15 years ago
Vasil Dimov	f6acea697e	Suppress InnoDB warning about long semaphore wait if running under Valgrind Sometimes Valgrind could be extremely slow and could trigger the InnoDB diagnostic message making the test to fail.	15 years ago
Vasil Dimov	66c518dcef	Speed up innodb_bug57255.test Submitted by: Stewart Smith (via internals@lists.mysql.com)	15 years ago
Sergey Glukhov	cd36a6a5d5	Fixed following problems: --Bug#52157 various crashes and assertions with multi-table update, stored function --Bug#54475 improper error handling causes cascading crashing failures in innodb/ndb --Bug#57703 create view cause Assertion failed: 0, file .\item_subselect.cc, line 846 --Bug#57352 valgrind warnings when creating view --Recently discovered problem when a nested materialized derived table is used before being populated and it leads to incorrect result We have several modes when we should disable subquery evaluation. The reasons for disabling are different. It could be uselessness of the evaluation as in case of 'CREATE VIEW' or 'PREPARE stmt', or we should disable subquery evaluation if tables are not locked yet as it happens in bug#54475, or too early evaluation of subqueries can lead to wrong result as it happened in Bug#19077. Main problem is that if subquery items are treated as const they are evaluated in ::fix_fields(), ::fix_length_and_dec() of the parental items as a lot of these methods have Item::val_...() calls inside. We have to make subqueries non-const to prevent unnecessary subquery evaluation. At the moment we have different methods for this. Here is a list of these modes: 1. PREPARE stmt; We use UNCACHEABLE_PREPARE flag. It is set during parsing in sql_parse.cc, mysql_new_select() for each SELECT_LEX object and cleared at the end of PREPARE in sql_prepare.cc, init_stmt_after_parse(). If this flag is set subquery becomes non-const and evaluation does not happen. 2. CREATE\|ALTER VIEW, SHOW CREATE VIEW, I_S tables which process FRM files We use LEX::view_prepare_mode field. We set it before view preparation and check this flag in ::fix_fields(), ::fix_length_and_dec(). Some bugs are fixed using this approach, some are not(Bug#57352, Bug#57703). The problem here is that we have a lot of ::fix_fields(), ::fix_length_and_dec() where we use Item::val_...() calls for const items. 3. Derived tables with subquery = wrong result(Bug19077) The reason of this bug is too early subquery evaluation. It was fixed by adding Item::with_subselect field The check of this field in appropriate places prevents const item evaluation if the item have subquery. The fix for Bug19077 fixes only the problem with convert_constant_item() function and does not cover other places(::fix_fields(), ::fix_length_and_dec() again) where subqueries could be evaluated. Example: CREATE TABLE t1 (i INT, j BIGINT); INSERT INTO t1 VALUES (1, 2), (2, 2), (3, 2); SELECT * FROM (SELECT MIN(i) FROM t1 WHERE j = SUBSTRING('12', (SELECT * FROM (SELECT MIN(j) FROM t1) t2))) t3; DROP TABLE t1; 4. Derived tables with subquery where subquery is evaluated before table locking(Bug#54475, Bug#52157) Suggested solution is following: -Introduce new field LEX::context_analysis_only with the following possible flags: #define CONTEXT_ANALYSIS_ONLY_PREPARE 1 #define CONTEXT_ANALYSIS_ONLY_VIEW 2 #define CONTEXT_ANALYSIS_ONLY_DERIVED 4 -Set/clean these flags when we perform context analysis operation -Item_subselect::const_item() returns result depending on LEX::context_analysis_only. If context_analysis_only is set then we return FALSE that means that subquery is non-const. As all subquery types are wrapped by Item_subselect it allow as to make subquery non-const when it's necessary.	15 years ago
Sergey Glukhov	0e77c3295a	Bug#39828 : Autoinc wraps around when offset and increment > 1 Auto increment value wraps when performing a bulk insert with auto_increment_increment and auto_increment_offset greater than one. The fix: If overflow happened then return MAX_ULONGLONG value as an indication of overflow and check this before storing the value into the field in update_auto_increment().	15 years ago
Sergey Glukhov	7704e3c2c2	Bug#56862 Execution of a query that uses index merge returns a wrong result In case of low memory sort buffer QUICK_INDEX_MERGE_SELECT creates temporary file where is stores row ids which meet QUICK_SELECT ranges except of clustered pk range, clustered range is processed separately. In init_read_record we check if temporary file is used and choose appropriate record access method. It does not take into account that temporary file contains partial result in case of QUICK_INDEX_MERGE_SELECT with clustered pk range. The fix is always to use rr_quick if QUICK_INDEX_MERGE_SELECT with clustered pk range is used.	15 years ago
Dmitry Shulga	ce3a7f4b01	Fixed bug#56619 - Assertion failed during ALTER TABLE RENAME, DISABLE KEYS. The code of ALTER TABLE RENAME, DISABLE KEYS could issue a commit while holding LOCK_open mutex. This is a regression introduced by the fix for Bug 54453. This failed an assert guarding us against a potential deadlock with connections trying to execute FLUSH TABLES WITH READ LOCK. The fix is to move acquisition of LOCK_open outside the section that issues ha_autocommit_or_rollback(). LOCK_open is taken to protect against concurrent operations with .frms and the table definition cache, and doesn't need to cover the call to commit. A test case added to innodb_mysql.test. The patch is to be null-merged to 5.5, which already has 54453 null-merged to it.	15 years ago
Marko Mäkelä	f2d39c9eaf	Bug #56680 wrong InnoDB results from a case-insensitive covering index row_search_for_mysql(): When a secondary index record might not be visible in the current transaction's read view and we consult the clustered index and optionally some undo log records, return the relevant columns of the clustered index record to MySQL instead of the secondary index record. REC_INFO_DELETED_FLAG: Move the definition from rem0rec.ic to rem0rec.h. ibuf_insert_to_index_page_low(): New function, refactored from ibuf_insert_to_index_page(). ibuf_insert_to_index_page(): When we are inserting a record in place of a delete-marked record and some fields of the record differ, update that record just like row_ins_sec_index_entry_by_modify() would do. mysql_row_templ_t: Add clust_rec_field_no. row_sel_store_mysql_rec(), row_sel_push_cache_row_for_mysql(): Add the flag rec_clust, for returning data at clust_rec_field_no instead of rec_field_no. Resurrect the debug assertion that the record not be marked for deletion. (Bug #55626) buf_LRU_free_block(): Refactored from buf_LRU_search_and_free_block(). This is needed for the innodb_change_buffering_debug diagnostics. [UNIV_DEBUG \|\| UNIV_IBUF_DEBUG] ibuf_debug, buf_page_get_gen(), buf_flush_page_try(): Implement innodb_change_buffering_debug=1 for evicting pages from the buffer pool, so that change buffering will be attempted more frequently.	15 years ago
Vasil Dimov	33496519e1	Fix Bug#57252 disabling innobase_stats_on_metadata disables ANALYZE In order to fix this bug we need to distinguish whether ha_innobase::info() has been called from ::analyze() or not. Rename ::info() to ::info_low() and add a boolean parameter that tells whether the call is from ::analyze() or not. Create a new simple ::info() that just calls ::info_low(false => not called from analyze). From ::analyze() instead of ::info() call ::info_low(true => called from analyze). Approved by: Jimmy (rb://487)	15 years ago
Vasil Dimov	71550f7d35	Tune the test for Bug#56143 too many foreign keys causes output of show create table to become invalid Use a CREATE statement with all the FKs instead of ALTERing the table many times because it is faster (11 seconds vs 3 seconds).	15 years ago
Vasil Dimov	f19fa5277a	Fix Bug#56143 too many foreign keys causes output of show create table to become invalid Just remove the check whether the file is "too big". A similar code exists in ha_innobase::update_table_comment() but that method does not seem to be used.	15 years ago
Jimmy Yang	34c61d0448	Fix Bug #57255 Cascade Delete results in "Got error -1 from storage engine". rb://477 approved by Marko	15 years ago
Marko Mäkelä	484e61a778	Bug#56716 InnoDB locks a record gap without locking the table row_search_for_mysql(): Acquire an intention lock on the table before locking the first record gap.	15 years ago
Bjorn Munch	b094cad9b0	Small test fix after 56753	15 years ago
Magne Mahre	24fc7ca4c8	Bug#39932 "create table fails if column for FK is in different case than in corr index". Server was unable to find existing or explicitly created supporting index for foreign key if corresponding statement clause used field names in case different than one used in key specification and created yet another supporting index. In cases when name of constraint (and thus name of generated index) was the same as name of existing/explicitly created index this led to duplicate key name error. The problem was that unlike all other code Key_part_spec::operator==() compared field names in case sensitive fashion. As result routines responsible for getting rid of redundant generated supporting indexes for foreign key were not working properly for versions of field names using different cases. (backported from mysql-trunk)	16 years ago
Sergey Vojtovich	0648087ca0	Fixed race condition in a test case for BUG#55580.	16 years ago
Evgeny Potemkin	151af144ff	Bug #55656 : mysqldump can be slower after bug 39653 fix. After fix for bug 39653 the shortest available secondary index was used for full table scan. Primary clustered key was used only if no secondary index can be used. However, when chosen secondary index includes all fields of the table being scanned it's better to use primary index since the amount of data to scan is the same but the primary index is clustered. Now the find_shortest_key function takes this into account.	16 years ago
Georgi Kodinov	3b36a677ba	Bug #55826 : create table .. select crashes with when KILL_BAD_DATA is returned Two problems discovered with the LEAST()/GREATEST() functions: 1. The check for a null value should happen even after the second call to val_str() in the args. This is important because two subsequent calls to the same Item::val_str() may yield different results. Fixed by checking for NULL value before dereferencing the string result. 2. While looping over the arguments and evaluating them the loop should stop if there was an error evaluating so far or the statement was killed. Fixed by checking for error and bailing out.	16 years ago
Georgi Kodinov	12f7d57d42	Bug #55580 : segfault in read_view_sees_trx_id The server was not checking for errors generated during the execution of Item::val_xxx() methods when copying data to the group, order, or distinct temp table's row. Fixed by extending the copy_funcs() to return an error code and by checking for that error code on the places copy_funcs() is called. Test case added.	16 years ago
Sunny Bains	6c0f9301ea	Fix Bug #55277 - Failing assertion: auto_inc > 0 Handle overflow when reading value from SELECT MAX(C) FROM T; Call ha_innobase::info() after initializing the autoinc value in ha_innobase::open(). Fix for both the builtin and plugin. rb://402	16 years ago
Jon Olav Hauglid	60edcf9475	Bug #54117 crash in thr_multi_unlock, temporary table This crash occured after ALTER TABLE was used on a temporary transactional table locked by LOCK TABLES. Any later attempts to execute LOCK/UNLOCK TABLES, caused the server to crash. The reason for the crash was the list of locked tables would end up having a pointer to a free'd table instance. This happened because ALTER TABLE deleted the table without also removing the table reference from the locked tables list. This patch fixes the problem by making sure ALTER TABLE also removes the table from the locked tables list. Test case added to innodb_mysql.test.	16 years ago
Jimmy Yang	f0fe99523c	Add innodb_bug53756-master.opt for innodb_bug53756 test.	16 years ago
Jimmy Yang	67d06a5459	Change the table name in innodb_bug54044 to lower case to avoid platform dependent diffs.	16 years ago
Jimmy Yang	dec24a7dd8	Check in fix for bug #53756 : "ALTER TABLE ADD PRIMARY KEY affects crash recovery" rb://369 approved by Marko	16 years ago
Jimmy Yang	c7afb80fe0	Fix Bug #54044 Create temporary tables and using innodb crashes.	16 years ago
Jimmy Yang	1b5d6a33b6	Move the fix for bug #54044 to security branch, and revert commit -r3520:3521.	16 years ago
Jimmy Yang	4bde58257d	Fix bug #54044 , Create temporary tables and using innodb crashes. Screen out NULL type columns, and return without creating the table. rb://378 approved by Marko	16 years ago
Vasil Dimov	9f57394ae4	Adjust suite/innodb/r/innodb_mysql.result after the merge	16 years ago
Marko Mäkelä	8371438494	Bug #38999 : Re-enable innodb_multi_update.test	16 years ago
Sergey Glukhov	d2db80c8d4	Bug#38999 valgrind warnings for update statement in function compare_record() Valgrind warning happpens because of uninitialized null bytes. In row_sel_push_cache_row_for_mysql() function we fill fetch cache with necessary field values, row_sel_store_mysql_rec() is called for this and leaves null bytes untouched. Later row_sel_pop_cached_row_for_mysql() rewrites table record buffer with uninited null bytes. We can see the problem from the test case: At 'SELECT...' we call row_sel_push...->row_sel_store...->row_sel_pop_cached... chain which rewrites table->record[0] buffer with uninitialized null bytes. When we call 'UPDATE...' statement, compare_record uses this buffer and valgrind warning occurs. The fix is to init null bytes with default values.	16 years ago
Marko Mäkelä	d38ef4e6c2	Move some InnoDB tests to mysql-test/suite/innodb.	16 years ago
Marko Mäkelä	4a8aa70eb8	Bug#53674: InnoDB: Error: unlock row could not find a 4 mode lock on the record In semi-consistent read, only unlock freshly locked non-matching records. Define DB_SUCCESS_LOCKED_REC for indicating a successful operation where a record lock was created. lock_rec_lock_fast(): Return LOCK_REC_SUCCESS, LOCK_REC_SUCCESS_CREATED, or LOCK_REC_FAIL instead of TRUE/FALSE. lock_sec_rec_read_check_and_lock(), lock_clust_rec_read_check_and_lock(), lock_rec_enqueue_waiting(), lock_rec_lock_slow(), lock_rec_lock(), row_ins_set_shared_rec_lock(), row_ins_set_exclusive_rec_lock(), sel_set_rec_lock(), row_sel_get_clust_rec_for_mysql(): Return DB_SUCCESS_LOCKED_REC if a new record lock was created. Adjust callers. row_unlock_for_mysql(): Correct the function documentation. row_prebuilt_t::new_rec_locks: Correct the documentation.	16 years ago
Marko Mäkelä	4d61acb187	Work around Bug #53750 in innodb.innodb_bug48024	16 years ago

1 2

100 Commits (22b38304836ff60d9929e0988676a33397c45b45)