An error occurred fetching the project authors.
- 05 Oct, 2009 1 commit
-
-
Guilhem Bichot authored
Backport of the fix for BUG#33730 "Full table scan instead selected partitions for query more than 10 partitions" from 6.0, made in sergefp@mysql.com-20090205190644-q8632sniogedhtsu
-
- 29 Sep, 2009 1 commit
-
-
Alfranio Correia authored
NOTE: Backporting the patch to next-mr. WL#4828 Augment DBUG_ENTER/DBUG_EXIT to crash MySQL in different functions ------- The assessment of the replication code in the presence of faults is extremely import to increase reliability. In particular, one needs to know if servers will either correctly recovery or print out appropriate error messages thus avoiding unexpected problems in a production environment. In order to accomplish this, the current patch refactories the debug macros already provided in the source code and introduces three new macros that allows to inject faults, specifically crashes, while entering or exiting a function or method. For instance, to crash a server while returning from the init_slave function (see module sql/slave.cc), one needs to do what follows: 1 - Modify the source replacing DBUG_RETURN by DBUG_CRASH_RETURN; DBUG_CRASH_RETURN(0); 2 - Use the debug variable to activate dbug instructions: SET SESSION debug="+d,init_slave_crash_return"; The new macros are briefly described below: DBUG_CRASH_ENTER (function) is equivalent to DBUG_ENTER which registers the beginning of a function but in addition to it allows for crashing the server while entering the function if the appropriate dbug instruction is activate. In this case, the dbug instruction should be "+d,function_crash_enter". DBUG_CRASH_RETURN (value) is equivalent to DBUG_RETURN which notifies the end of a function but in addition to it allows for crashing the server while returning from the function if the appropriate dbug instruction is activate. In this case, the dbug instruction should be "+d,function_crash_return". Note that "function" should be the same string used by either the DBUG_ENTER or DBUG_CRASH_ENTER. DBUG_CRASH_VOID_RETURN (value) is equivalent to DBUG_VOID_RETURN which notifies the end of a function but in addition to it allows for crashing the server while returning from the function if the appropriate dbug instruction is activate. In this case, the dbug instruction should be "+d,function_crash_return". Note that "function" should be the same string used by either the DBUG_ENTER or DBUG_CRASH_ENTER. To inject other faults, for instance, wrong return values, one should rely on the macros already available. The current patch also removes a set of macros that were either not being used or were redundant as other macros could be used to provide the same feature. In the future, we also consider dynamic instrumentation of the code. BUG#45747 DBUG_CRASH_* is not setting the strict option --------- When combining DBUG_CRASH_* with "--debug=d:t:i:A,file" the server crashes due to a call to the abort function in the DBUG_CRASH_* macro althought the appropriate keyword has not been set.
-
- 23 Sep, 2009 1 commit
-
-
Staale Smedseng authored
with gcc 4.3.2 Cleaning up warnings not present in 5.0.
-
- 10 Sep, 2009 2 commits
-
-
Mikael Ronstrom authored
-
Mikael Ronstrom authored
WL#4571, Enable Key cache defined for a partition to enable more scalability on partitioned MyISAM tables among other things
-
- 02 Sep, 2009 1 commit
-
-
Georgi Kodinov authored
-
- 26 Aug, 2009 1 commit
-
-
Mattias Jonsson authored
Problem was that the partition containing NULL values was pruned away, since '2001-01-01' < '2001-02-00' but TO_DAYS('2001-02-00') is NULL. Added the NULL partition for RANGE/LIST partitioning on TO_DAYS() function to be scanned too. Also fixed a bug that added ALLOW_INVALID_DATES to sql_mode (SELECT * FROM t WHERE date_col < '1999-99-99' on a RANGE/LIST partitioned table would add it).
-
- 06 Aug, 2009 1 commit
-
-
Mattias Jonsson authored
when partition is reoganized. Problem was that table->timestamp_field_type was not changed before copying rows between partitions. fixed by setting it to TIMESTAMP_NO_AUTO_SET as the first thing in fast_alter_partition_table, so that all if-branches is covered.
-
- 31 Jul, 2009 1 commit
-
-
Tatiana A. Nurnberg authored
We disallow the partitioning of a log table. You could however partition a table first, and then point logging to it. This is not only against the docs, it also crashes the server. We catch this case now.
-
- 08 Jul, 2009 1 commit
-
-
Georgi Kodinov authored
Item_field::fix_fields()
-
- 02 Jul, 2009 1 commit
-
-
Georgi Kodinov authored
contains ONLY_FULL_GROUP_BY The partitioning code needs to issue a Item::fix_fields() on the partitioning expression in order to prepare it for being evaluated. It does this by creating a special table and a table list for the scope of the partitioning expression. But when checking ONLY_FULL_GROUP_BY the Item_field::fix_fields() was relying that there always be cached_table set and was trying to use it to get the select_lex of the SELECT the field's table is in. But the cached_table was not set by the partitioning code that creates the artificial TABLE_LIST used to resolve the partitioning expression and this resulted in a crash. Fixed by rectifying the following errors : 1. Item_field::fix_fields() : the code that check for ONLY_FULL_GROUP_BY relies on having tables with cacheable_table set. This is mostly true, the only two exceptions being the partitioning context table and the trigger context table. Fixed by taking the current parsing context if no pointer to the TABLE_LIST instance is present in the cached_table. 2. fix_fields_part_func() : 2a. The code that adds the table being created to the scope for the partitioning expression is mostly a copy of the add_table_to_list and friends with one exception : it was not marking the table as cacheable (something that normal add_table_to_list is doing). This caused the problem in the check for ONLY_FULL_GROUP_BY in Item_field::fix_fields() to appear. Fixed by setting the correct members to make the table cacheable. The ideal structural fix for this is to use a unified interface for adding a table to a table list (add_table_to_list?) : noted in a TODO comment 2b. The Item::fix_fields() was called with a NULL destination pointer. This causes uninitalized memory reads in the overloaded ::fix_fields() function (namely Item_field::fix_fields()) as it expects a non-zero pointer there. Fixed by passing the source pointer similarly to how it's done in JOIN::prepare().
-
- 19 Jun, 2009 1 commit
-
-
Sergey Glukhov authored
The problem: described in the bug report. The fix: --increase buffers where it's necessary (buffers which are used in stxnmov) --decrease buffer lengths which are used
-
- 01 Apr, 2009 1 commit
-
-
Ramil Kalimullin authored
Problem: we don't prune a LESS THAN partition if MAXVALUE is given and given value is equal to a LESS THAN value. Fix: prune partitions in such cases.
-
- 09 Jan, 2009 1 commit
-
-
Mattias Jonsson authored
post push fix, added test found a valgrind warning
-
- 28 Dec, 2008 1 commit
-
-
Mattias Jonsson authored
Problem was an errornous date that lead to end partition was before the start, leading to a crash. Solution was to check greater or equal instead of only equal between start and end partition. NOTE: partitioning pruning handles incorrect dates differently than index lookup, which can give different results in a partitioned table versus a non partitioned table for queries having 'bad' dates in the where clause.
-
- 02 Dec, 2008 1 commit
-
-
Mattias Jonsson authored
The non documented command 'ALTER PARTITION t REORGANIZE PARTITION' (without any partitions!) which only make sense for nativly partitioned engines, such as NDB, crashes the server if there was no change of number of partitions. The problem was wrong usage of fast_end_partition function, which led to usage of a non initialized variable.
-
- 12 Nov, 2008 1 commit
-
-
Mattias Jonsson authored
Occurred with EXTRA_DEBUG on windows. Problem was insufficient length of a local variable that stored path names. Solution was to use the correct length.
-
- 10 Nov, 2008 1 commit
-
-
Build Team authored
since Oct 1st
-
- 04 Nov, 2008 1 commit
-
-
Mattias Jonsson authored
The partitioning clause is only a very long single line, which is very hard to interpret for a human. This patch breaks the partitioning syntax into one line for the partitioning type, and one line per partition/subpartition.
-
- 10 Oct, 2008 1 commit
-
-
Mattias Jonsson authored
on non-partitioned table Problem was that partitioning specific commands was accepted for non partitioned tables and treated like ANALYZE/CHECK/OPTIMIZE/REPAIR TABLE, after bug-20129 was fixed, which changed the code path from mysql_alter_table to mysql_admin_table. Solution was to check if the table was partitioned before trying to execute the admin command
-
- 06 Oct, 2008 3 commits
-
-
Alexey Botchkov authored
-
Alexey Botchkov authored
-
Alexey Botchkov authored
problems are located in the sql_partition.cc where functions calculation partition_id don't expect error returned from item->val_int(). Fixed by adding checks to these functions. Note - it tries to fix more problems than just the reported bug. per-file comments: modified: mysql-test/r/partition.result Bug#38083 Error-causing row inserted into partitioned table despite error test result mysql-test/t/partition.test Bug#38083 Error-causing row inserted into partitioned table despite error test case sql/opt_range.cc Bug#38083 Error-causing row inserted into partitioned table despite error get_part_id() call fixed sql/partition_info.h Bug#38083 Error-causing row inserted into partitioned table despite error get_subpart_id_func interface changed. sql/sql_partition.cc Bug#38083 Error-causing row inserted into partitioned table despite error various functions calculationg partition_id and subpart_id didn't expect an error returned from item->val_int(). Error checks added.
-
- 04 Oct, 2008 1 commit
-
-
Mattias Jonsson authored
InnoDB Plugin locks table The fast/on-line add/drop index handler calls was not implemented whithin the partitioning. This implements it in the partitioning handler. Since this is only used by the not included InnoDB plugin, there is no test case. (Have tested it manually with the plugin, and it does not allow unique indexes not including partitioning function, or removal of pk, which in innodb generates a new pk, which is not in the partitioning function.) NOTE: This introduces a new handler method, and because of that changes the storage engine api. (One cannot use a handlerton to see the capabilities of a table's handler if it is partitioned. So I added a wrapper function in the handler that defaults to the handlerton function, which the partitioning handler overrides.
-
- 11 Aug, 2008 1 commit
-
-
Mattias Jonsson authored
partition is corrupt The main problem was that ALTER TABLE t ANALYZE/CHECK/OPTIMIZE/REPAIR PARTITION took another code path (over mysql_alter_table instead of mysql_admin_table) which differs in two ways: 1) alter table opens the tables in a different way than admin tables do resulting in returning with error before it tried the command 2) alter table does not start to send any diagnostic rows to the client which the lower admin functions continue to use -> resulting in assertion crash The fix: Remapped ALTER TABLE t ANALYZE/CHECK/OPTIMIZE/REPAIR PARTITION to use the same code path as ANALYZE/CHECK/OPTIMIZE/REPAIR TABLE t. Adding check in mysql_admin_table to setup the partition list for which partitions that should be used. Partitioned tables will still not work with REPAIR TABLE/PARTITION USE_FRM, since that requires moving partitions to tables, REPAIR TABLE t USE_FRM, and check that the data still fulfills the partitioning function and then move the table back to being a partition. NOTE: I have removed the following functions from the handler interface: analyze_partitions, check_partitions, optimize_partitions, repair_partitions Since they are not longer needed. THIS ALTERS THE STORAGE ENGINE API
-
- 25 Feb, 2008 1 commit
-
-
mattiasj@witty. authored
Fixed a missed case in the patch for Bug#31931. Also makes Bug#33722 a duplicate of Bug#31931. Added tests for better coverage. Replaced some legacy function calls.
-
- 19 Feb, 2008 2 commits
-
-
kostja@dipika.(none) authored
does not send it to the client.
-
kostja@dipika.(none) authored
a SELECT doesn't cause ROLLBACK of statem". The idea of the fix is to ensure that we always commit the current statement at the end of dispatch_command(). In order to not issue redundant disc syncs, an optimization of the two-phase commit protocol is implemented to bypass the two phase commit if the transaction is read-only.
-
- 13 Feb, 2008 1 commit
-
-
mikael@dator6.(none) authored
Handle error case of not being able to reopen which requires us to remove table from thread's open list and table_cache.
-
- 11 Feb, 2008 1 commit
-
-
Problem was that it did not work with corrupted/crashed tables. Solution is to disable these commands until WL#4176 is completed
-
- 28 Jan, 2008 2 commits
-
-
mikael@dator6.(none) authored
-
mikael@dator6.(none) authored
-
- 09 Jan, 2008 1 commit
-
-
Problem was that the mix of handlers was not consistent between CREATE and ALTER changed so that it works like: - All partitions must use the same engine AND it must be the same as the table. - if one does NOT specify an engine on the table level then one must either NOT specify any engine on any partition/subpartition OR for ALL partitions/subpartitions Note: that after a table have been created, the storage engine is specified for all parts of the table (table/partition/subpartition) and so when using alter, one does not need to specify it (unless one wants to change the storage engine, then one have to specify it on the table level)
-
- 20 Dec, 2007 1 commit
-
-
kostja@bodhi.(none) authored
called from a SELECT doesn't cause ROLLBACK of state" Make private all class handler methods (PSEA API) that may modify data. Introduce and deploy public ha_* wrappers for these methods in all sql/. This necessary to keep track of all data modifications in sql/, which is in turn necessary to be able to optimize two-phase commit of those transactions that do not modify data.
-
- 12 Dec, 2007 1 commit
-
-
kostja@bodhi.(none) authored
cause ROLLBACK of statement", part 1. Review fixes. Do not send OK/EOF packets to the client until we reached the end of the current statement. This is a consolidation, to keep the functionality that is shared by all SQL statements in one place in the server. Currently this functionality includes: - close_thread_tables() - log_slow_statement(). After this patch and the subsequent patch for Bug#12713, it shall also include: - ha_autocommit_or_rollback() - net_end_statement() - query_cache_end_of_result(). In future it may also include: - mysql_reset_thd_for_next_command().
-
- 26 Nov, 2007 1 commit
-
-
Problems: 1. looking for a matching partition we miss the fact that the maximum allowed value is in the PARTITION p LESS THAN MAXVALUE. 2. one can insert maximum value if numeric maximum value is the last range. (should only work if LESS THAN MAXVALUE). 3. one cannot have both numeric maximum value and MAXVALUE string as ranges (the same value, but different meanings). Fix: consider the maximum value as a supremum.
-
- 23 Nov, 2007 1 commit
-
-
gluh@mysql.com/eagle.(none) authored
The crash happens because we change share->partition_info where 'share' is global struct (it affects other threads which use the same 'share'). It causes discrepancy between 'share' and handler data. The fix: Move share->partition_info update into WFRM_INSTALL_SHADOW part which is protected by OPEN_lock.
-
- 20 Nov, 2007 1 commit
-
-
Problem was for LINEAR HASH/KEY. Crashes because of wrong partition id returned when creating the new altered partitions. (because of wrong linear hash mask) Solution: Update the linear hash mask before using it for the new altered table.
-
- 15 Nov, 2007 1 commit
-
-
istruewing@stella.local authored
corrupts a MERGE table Bug 26867 - LOCK TABLES + REPAIR + merge table result in memory/cpu hogging Bug 26377 - Deadlock with MERGE and FLUSH TABLE Bug 25038 - Waiting TRUNCATE Bug 25700 - merge base tables get corrupted by optimize/analyze/repair table Bug 30275 - Merge tables: flush tables or unlock tables causes server to crash Bug 19627 - temporary merge table locking Bug 27660 - Falcon: merge table possible Bug 30273 - merge tables: Can't lock file (errno: 155) The problems were: Bug 26379 - Combination of FLUSH TABLE and REPAIR TABLE corrupts a MERGE table 1. A thread trying to lock a MERGE table performs busy waiting while REPAIR TABLE or a similar table administration task is ongoing on one or more of its MyISAM tables. 2. A thread trying to lock a MERGE table performs busy waiting until all threads that did REPAIR TABLE or similar table administration tasks on one or more of its MyISAM tables in LOCK TABLES segments do UNLOCK TABLES. The difference against problem #1 is that the busy waiting takes place *after* the administration task. It is terminated by UNLOCK TABLES only. 3. Two FLUSH TABLES within a LOCK TABLES segment can invalidate the lock. This does *not* require a MERGE table. The first FLUSH TABLES can be replaced by any statement that requires other threads to reopen the table. In 5.0 and 5.1 a single FLUSH TABLES can provoke the problem. Bug 26867 - LOCK TABLES + REPAIR + merge table result in memory/cpu hogging Trying DML on a MERGE table, which has a child locked and repaired by another thread, made an infinite loop in the server. Bug 26377 - Deadlock with MERGE and FLUSH TABLE Locking a MERGE table and its children in parent-child order and flushing the child deadlocked the server. Bug 25038 - Waiting TRUNCATE Truncating a MERGE child, while the MERGE table was in use, let the truncate fail instead of waiting for the table to become free. Bug 25700 - merge base tables get corrupted by optimize/analyze/repair table Repairing a child of an open MERGE table corrupted the child. It was necessary to FLUSH the child first. Bug 30275 - Merge tables: flush tables or unlock tables causes server to crash Flushing and optimizing locked MERGE children crashed the server. Bug 19627 - temporary merge table locking Use of a temporary MERGE table with non-temporary children could corrupt the children. Temporary tables are never locked. So we do now prohibit non-temporary chidlren of a temporary MERGE table. Bug 27660 - Falcon: merge table possible It was possible to create a MERGE table with non-MyISAM children. Bug 30273 - merge tables: Can't lock file (errno: 155) This was a Windows-only bug. Table administration statements sometimes failed with "Can't lock file (errno: 155)". These bugs are fixed by a new implementation of MERGE table open. When opening a MERGE table in open_tables() we do now add the child tables to the list of tables to be opened by open_tables() (the "query_list"). The children are not opened in the handler at this stage. After opening the parent, open_tables() opens each child from the now extended query_list. When the last child is opened, we remove the children from the query_list again and attach the children to the parent. This behaves similar to the old open. However it does not open the MyISAM tables directly, but grabs them from the already open children. When closing a MERGE table in close_thread_table() we detach the children only. Closing of the children is done implicitly because they are in thd->open_tables. For more detail see the comment at the top of ha_myisammrg.cc. Changed from open_ltable() to open_and_lock_tables() in all places that can be relevant for MERGE tables. The latter can handle tables added to the list on the fly. When open_ltable() was used in a loop over a list of tables, the list must be temporarily terminated after every table for open_and_lock_tables(). table_list->required_type is set to FRMTYPE_TABLE to avoid open of special tables. Handling of derived tables is suppressed. These details are handled by the new function open_n_lock_single_table(), which has nearly the same signature as open_ltable() and can replace it in most cases. In reopen_tables() some of the tables open by a thread can be closed and reopened. When a MERGE child is affected, the parent must be closed and reopened too. Closing of the parent is forced before the first child is closed. Reopen happens in the order of thd->open_tables. MERGE parents do not attach their children automatically at open. This is done after all tables are reopened. So all children are open when attaching them. Special lock handling like mysql_lock_abort() or mysql_lock_remove() needs to be suppressed for MERGE children or forwarded to the parent. This depends on the situation. In loops over all open tables one suppresses child lock handling. When a single table is touched, forwarding is done. Behavioral changes: =================== This patch changes the behavior of temporary MERGE tables. Temporary MERGE must have temporary children. The old behavior was wrong. A temporary table is not locked. Hence even non-temporary children were not locked. See Bug 19627 - temporary merge table locking. You cannot change the union list of a non-temporary MERGE table when LOCK TABLES is in effect. The following does *not* work: CREATE TABLE m1 ... ENGINE=MRG_MYISAM ...; LOCK TABLES t1 WRITE, t2 WRITE, m1 WRITE; ALTER TABLE m1 ... UNION=(t1,t2) ...; However, you can do this with a temporary MERGE table. You cannot create a MERGE table with CREATE ... SELECT, neither as a temporary MERGE table, nor as a non-temporary MERGE table. CREATE TABLE m1 ... ENGINE=MRG_MYISAM ... SELECT ...; Gives error message: table is not BASE TABLE.
-
- 11 Nov, 2007 1 commit
-
-
mattiasj@mattiasj-laptop.(none) authored
causes the Server to crash. Post-pushbuild fix Pushbuild genereted valgrind warnings. Changed function to safer variant.
-