An error occurred fetching the project authors.
- 17 Feb, 2014 1 commit
-
-
Sergey Petrunya authored
MDEV-5555: Incorrect index_merge on BTREE indices - In ha_partition, make ordered index reads return rows in rowid order when index columns are the same.
-
- 14 Feb, 2013 1 commit
-
-
Mattias Jonsson authored
DOWNGRADED FROM 5.6.11 TO 5.6.10 Problem was new syntax not accepted by previous version. Fixed by adding version comment of /*!50531 around the new syntax. Like this in the .frm file: 'PARTITION BY KEY /*!50611 ALGORITHM = 2 */ () PARTITIONS 3' and also changing the output from SHOW CREATE TABLE to: CREATE TABLE t1 (a INT) /*!50100 PARTITION BY KEY */ /*!50611 ALGORITHM = 1 */ /*!50100 () PARTITIONS 3 */ It will always add the ALGORITHM into the .frm for KEY [sub]partitioned tables, but for SHOW CREATE TABLE it will only add it in case it is the non default ALGORITHM = 1. Also notice that for 5.5, it will say /*!50531 instead of /*!50611, which will make upgrade from 5.5 > 5.5.31 to 5.6 < 5.6.11 fail! If one downgrades an fixed version to the same major version (5.5 or 5.6) the bug 14521864 will be visible again, but unless the .frm is updated, it will work again when upgrading again. Also fixed so that the .frm does not get updated version if a single partition check passes.
-
- 31 Oct, 2012 1 commit
-
-
Michael Widenius authored
mysql-test/r/partition.result: Added test case mysql-test/t/partition.test: Added test case sql/ha_partition.cc: Removed printing of not initialized variable storage/maria/ha_maria.cc: Don't copy variables that are not initialized
-
- 15 Aug, 2012 1 commit
-
-
Michael Widenius authored
mysql-test/r/partition.result: Added test case mysql-test/t/partition.test: Added test case sql/sql_partition.cc: Do mysql_trans_prepare_alter_copy_data() after all original tables are locked. (We don't want to disable transactions for the original tables, that still may be in the cache) sql/sql_table.cc: Fixed two wrong DBUG_ENTER
-
- 24 May, 2012 1 commit
-
-
unknown authored
Analysis: The problem in the original MySQL bug is that the range optimizer performs its analysis in a separate MEM_ROOT object that is freed after the range optimzier is done. During range analysis get_mm_tree calls Item_func_like::select_optimize, which in turn evaluates its right argument. In the test case the right argument is a subquery. In MySQL, subqueries are optimized lazyly, thus the call to val_str triggers optimization for the subquery. All objects needed by the subquery plan end up in the temporary MEM_ROOT used by the range optimizer. When execution ends, the JOIN::cleanup process tries to cleanup objects of the subquery plan, but all these objects are gone with the temporary MEM_ROOT. The solution for MySQL is to switch the mem_root. In MariaDB with the patch for bug lp:944706, all constant subqueries that may be used by the optimization process are preoptimized. Therefore Item_func_like::select_optimize only triggers subquery execution, and the above problem is not present. The patch however adds a test whether the evaluated right argument of the LIKE predicate is expensive. This is consistent with our approach not to evaluate expensive expressions during optimization.
-
- 27 Jan, 2012 1 commit
-
-
Tor Didriksen authored
Bug#13011410 CRASH IN FILESORT CODE WITH GROUP BY/ROLLUP The assert in 13580775 is visible in 5.6 only, but shows that all versions are vulnerable. 13011410 crashes in all versions. filesort tries to re-use the sort buffer between invocations in order to save malloc/free overhead. The fix for Bug 11748783 - 37359: FILESORT CAN BE MORE EFFICIENT. added an assert that buffer properties (num_records, record_length) are consistent between invocations. Indeed, they are not necessarily consistent. Fix: re-allocate the sort buffer if properties change. mysql-test/r/partition.result: New tests. mysql-test/t/partition.test: New tests. sql/filesort.cc: If we already have allocated a sort buffer in a previous execution, then verify that it is big enough for the current one. sql/table.h: Add sort_keys_size; Number of bytes allocated for the sort_keys buffer.
-
- 13 Jan, 2012 1 commit
-
-
Michael Widenius authored
-
- 12 Dec, 2011 1 commit
-
-
Sergei Golubchik authored
* rename all debugging related command-line options and variables to start from "debug-", and made them all OFF by default. * replace "MySQL" with "MariaDB" in error messages * "Cast ... converted ... integer to it's ... complement" is now a note, not a warning * @@query_cache_strip_comments now has a session scope, not global.
-
- 15 Jun, 2011 1 commit
-
-
Sergey Petrunya authored
- Testcase
-
- 29 Apr, 2011 1 commit
-
-
Mattias Jonsson authored
The partitioning engine checked the auto_increment column even if it was not to be written, triggering a DBUG_ASSERT. Fixed by checking if table->write_set for that column was set.
-
- 16 Mar, 2011 1 commit
-
-
Mattias Jonsson authored
Bug#28928: UNIX_TIMESTAMP() should be considered unary monotonic by partition pruning Made UNIX_TIMESTAMP MONOTONIC_INCREASING when it have TIMESTAMP argument (only).
-
- 21 Feb, 2011 1 commit
-
-
Jorgen Loland authored
UPDATES THE TABLE ENTRIES (formerly 55385) BUG#11764529: MULTI UPDATE+INNODB REPORTS ER_KEY_NOT_FOUND IF A TABLE IS UPDATED TWICE (formerly 57373) If multiple-table update updates a row through two aliases and the first update physically moves the row, the second update will fail to locate the row. This results in different errors depending on storage engine: * MyISAM: Got error 134 from storage engine * InnoDB: Can't find record in 'tbl' None of these errors accurately describe the problem. Furthermore, since MyISAM is non-transactional, the update executed first will be performed while the second will not. In addition, for two equal multiple-table update statements, one could succeed and the other fail based on whether or not the record actually moved or not. This was inconsistent. Two update operations may physically move a row: 1) Update of a column in a clustered primary key 2) Update of a column used to calculate which partition the row belongs to BUG#11764529 is about case 1) above, BUG#11762751 was about case 2). The fix for these bugs is to return with an error if multiple-table update is about to: a) Update a table through multiple aliases, and b) Perform an update that may physically more the row in at least one of these aliases This avoids * partial updates as described for MyISAM above, * provides the same error message that describes the actual problem for all SEs * inconsistent behavior where a statement fails or succeeds based on e.g. the partitioning algorithm of the table. mysql-test/r/multi_update.result: Add test for bug#57373 mysql-test/r/multi_update_innodb.result: Add test for bug#57373 mysql-test/r/partition.result: Add test for bug#55385 mysql-test/t/multi_update.test: Add test for bug#57373 mysql-test/t/multi_update_innodb.test: Add test for bug#57373 mysql-test/t/partition.test: Add test for bug#55385 sql/handler.cc: Translate handler error HA_ERR_RECORD_DELETED to server error sql/share/errmsg-utf8.txt: New error message for multi-table update where the same table is updated multiple times. sql/sql_update.cc: Add function unsafe_key_update()
-
- 09 Feb, 2011 1 commit
-
-
MySQL Build Team authored
> ------------------------------------------------------------ > revno: 3527.3.1 > revision-id: mattias.jonsson@oracle.com-20101222095036-2lpx0gqu4i45jtkz > parent: sven.sandberg@oracle.com-20101220090735-psae11j9nwuj8vzl > committer: Mattias Jonsson <mattias.jonsson@oracle.com> > branch nick: b54483-51-bt_2 > timestamp: Wed 2010-12-22 10:50:36 +0100 > message: > Bug#54483: valgrind errors when making warnings for multiline inserts into partition > Bug#57071: EXTRACT(WEEK from date_col) cannot be allowed as partitioning function > > There were functions allowed as partitioning functions > that implicit allowed cast. That could result in unacceptable > behaviour. > > Solution was to check that the arguments of date and time functions > have allowed types (field and date/datetime/time depending on function).
-
- 24 Jan, 2011 1 commit
-
-
Mattias Jonsson authored
Regression introduced in bug#52455. Problem was that the fixed function did not set the last used partition variable, resulting in wrong partition used when storing the position of the newly retrieved row. Fixed by setting the last used partition in ha_partition::index_read_idx_map.
-
- 22 Dec, 2010 1 commit
-
-
Mattias Jonsson authored
Bug#57071: EXTRACT(WEEK from date_col) cannot be allowed as partitioning function There were functions allowed as partitioning functions that implicit allowed cast. That could result in unacceptable behaviour. Solution was to check that the arguments of date and time functions have allowed types (field and date/datetime/time depending on function). mysql-test/r/partition.result: Updated result mysql-test/r/partition_error.result: Updated result mysql-test/suite/parts/inc/part_supported_sql_funcs_main.inc: disabled test with not allowed arguments. mysql-test/suite/parts/r/part_supported_sql_func_innodb.result: Updated result mysql-test/suite/parts/r/part_supported_sql_func_myisam.result: Updated result mysql-test/t/partition.test: Fixed typo in bug number and removed non allowed function (bad argument) mysql-test/t/partition_error.test: Added tests to verify correct type of argument. sql/item.h: Renamed processor since it is no longer only for timezone sql/item_func.h: Added help functions for checking date/time/datetime arguments. sql/item_timefunc.h: Added processors for argument correctness sql/sql_partition.cc: renamed the processor for checking arguments.
-
- 05 Nov, 2010 1 commit
-
-
Mattias Jonsson authored
It was possible to issue an ALTER TABLE ADD PRIMARY KEY on an partitioned InnoDB table that failed and crashed the server. The problem was that it succeeded to create the PK on at least one partition, and then failed on a subsequent partition, due to duplicate key violation. Since the partitions that already had added the PK was not reverted all partitions was not consistent with the table definition, which caused the crash. The solution was to add a revert step to ha_partition::add_index() that dropped the index for the already succeeded partitions, on failure. mysql-test/r/partition.result: updated result mysql-test/t/partition.test: Added test sql/ha_partition.cc: Only allow ADD/DROP flags in pairs, so that they can be reverted on failures. If add_index() fails for a partition, revert (drop the index) for the previous partitions. sql/handler.h: Added some extra info in a comment.
-
- 30 Sep, 2010 1 commit
-
-
Mattias Jonsson authored
Bug#57113: ha_partition::extra(ha_extra_function): Assertion `m_extra_cache' failed Fix for bug#55458 included DBUG_ASSERTS causing debug builds of the server to crash on another multi-table update. Removed the asserts since they where wrong. (updated after testing the patch in 5.5). mysql-test/r/partition.result: updated result mysql-test/t/partition.test: Added test for bug#57113 sql/ha_partition.cc: Removed the assert for m_extra_cache when ::extra(HA_PREPARE_FOR_UPDATE) was called.
-
- 30 Aug, 2010 1 commit
-
-
Mattias Jonsson authored
It was hard to understand what the error really meant. The error checking in partitioning is done in several different parts during the execution of a query which can make it hard to return useful errors. Added a new error for bad VALUES part in the per PARTITION clause. Using the more verbose error that a column is not allowed in the partitioning function instead of just that the function is not allowed. mysql-test/r/partition.result: changed error to be more specific mysql-test/r/partition_error.result: updated result mysql-test/std_data/parts/t1TIMESTAMP.frm: .frm file of CREATE TABLE t1 (a TIMESTAMP) PARTITION BY HASH(TO_DAYS(a)); mysql-test/t/partition.test: changed error to be more specific mysql-test/t/partition_error.test: Added test (also for verifying behaviour of previously created tables which is no longer allowed). Updated expected errors in other places sql/partition_info.cc: Added function report_part_expr_error to be able to return a more specific error. Renamed fix_func_partition to fix_partition_values since the function really fixes/checks the VALUES clause. sql/partition_info.h: removed part_result_type, since it was unused. renamed fix_funk_partition->fix_partition_values added report_part_expr_error sql/share/errmsg-utf8.txt: Added a more specific error. sql/sql_partition.cc: made use of report_part_expr_error to get a more specific error. sql/sql_yacc.yy: Changed error message to be more specific. And return an other error code.
-
- 27 Aug, 2010 1 commit
-
-
Mattias Jonsson authored
Bug#46754: 'rows' field doesn't reflect partition pruning Update of test results after fixing the above bugs. (fix in separate commit). mysql-test/r/partition.result: Updated test result after fixing bugs 46754 and 53806 mysql-test/r/partition_hash.result: Updated test result after fixing bugs 46754 and 53806 mysql-test/r/partition_innodb.result: Updated test result after fixing bugs 46754 and 53806 mysql-test/r/partition_range.result: Updated test result after fixing bugs 46754 and 53806 mysql-test/suite/parts/r/partition_alter3_innodb.result: Updated test result after fixing bugs 46754 and 53806 mysql-test/suite/parts/r/partition_alter3_myisam.result: Updated test result after fixing bugs 46754 and 53806
-
- 25 Aug, 2010 1 commit
-
-
Marc Alff authored
Before this fix, the ha_read_last_count status variable was defined and updated internally, for never exposed as a system variable. This fix exposes the system variable as "Handler_read_last", for completness of the Handler_read_* system variables interface. Adjusted tests results accordingly.
-
- 10 Aug, 2010 1 commit
-
-
Mattias Jonsson authored
Problem was that the handler call ::extra(HA_EXTRA_CACHE) was cached but the ::extra(HA_EXTRA_PREPARE_FOR_UPDATE) was not. Solution was to also cache the other call and forward it when moving to a new partition to scan. mysql-test/r/partition.result: test result mysql-test/t/partition.test: New test from bug report. sql/ha_partition.cc: cache the HA_EXTRA_PREPARE_FOR_UPDATE just like HA_EXTRA_CACHE. sql/ha_partition.h: Added cache flag for HA_EXTRA_PREPARE_FOR_UPDATE
-
- 19 May, 2010 1 commit
-
-
Alexander Nozdrin authored
from 6.0 to trunk-bugfixing.
-
- 05 Apr, 2010 1 commit
-
-
Sergey Petrunya authored
subqueries that are AND-parts of the WHERE - First code (needs cleanup).
-
- 22 Mar, 2010 1 commit
-
-
Sergey Vojtovich authored
myisam tables Queries following TRUNCATE of partitioned MyISAM table may crash server if myisam_use_mmap is true. Internally this is MyISAM bug, but limited to partitioned tables, because MyISAM doesn't use ::delete_all_rows() method for TRUNCATE, but goes via table recreate instead. MyISAM didn't properly fall back to non-mmaped I/O after mmap() failure. Was not repeatable on linux before, likely because (quote from man mmap): SUSv3 specifies that mmap() should fail if length is 0. However, in kernels before 2.6.12, mmap() succeeded in this case: no mapping was created and the call returned addr. Since kernel 2.6.12, mmap() fails with the error EINVAL for this case. mysql-test/r/partition.result: A test case for BUG#51868. mysql-test/t/partition.test: A test case for BUG#51868. storage/myisam/mi_delete_all.c: _mi_unmap_file() is compressed record format specific, which is read-only. As compressed MyISAM data files are read-only, we must never use _mi_unmap_file() in mi_delete_all_rows(). storage/myisam/mi_dynrec.c: Make myisam mmap code more durable to errors: - set file_read/file_write handlers if mmap succeeded; - reset file_read/file_write handlers on unmap. storage/myisam/mi_extra.c: Moved file_read/file_write handlers initialization to mi_dynmap_file(). storage/myisam/myisamdef.h: Added mi_munmap_file() declaration.
-
- 20 Feb, 2010 1 commit
-
-
Alexander Nozdrin authored
The task is to (a) add a comment on indexes and (b) increase the maximum length of column, table and the new index comments. The patch committed on behalf of Yoshinori Matsunobu (Yoshinori.Matsunobu@Sun.COM).
-
- 22 Dec, 2009 1 commit
-
-
Sergei Golubchik authored
-
- 14 Dec, 2009 1 commit
-
-
Alexey Kopytov authored
-
- 10 Dec, 2009 1 commit
-
-
Jon Olav Hauglid authored
Bug#40181 Made use of tdc_remove_table instead of just setting share->version to 0 to make sure all unused table instances go away as part of CREATE/ALTER TABLE.
-
- 25 Nov, 2009 1 commit
-
-
Magne Mahre authored
branch due to BUG#46853 Commented out the testcase for Bug#45816 in mysql-pe branch due to valgrind warnings. Please see Bug#46853
-
- 24 Nov, 2009 1 commit
-
-
Mattias Jonsson authored
mysql-test/r/log_tables.result: Bug #35765 ALTER TABLE produces wrong error when non-existent storage engine used Updated result mysql-test/r/partition.result: Bug #35765 ALTER TABLE produces wrong error when non-existent storage engine used Updated result mysql-test/r/partition_innodb.result: Bug #35765 ALTER TABLE produces wrong error when non-existent storage engine used Updated result mysql-test/t/log_tables.test: Bug #35765 ALTER TABLE produces wrong error when non-existent storage engine used Updated test mysql-test/t/partition.test: Bug #35765 ALTER TABLE produces wrong error when non-existent storage engine used Added test case mysql-test/t/partition_innodb.test: Bug #35765 ALTER TABLE produces wrong error when non-existent storage engine used Updated test sql/protocol.cc: Bug #35765 ALTER TABLE produces wrong error when non-existent storage engine used (fix of bug#48939 to avoid test failures on my test build). sql/sql_yacc.yy: Bug #35765 ALTER TABLE produces wrong error when non-existent storage engine used if no existing engine was given, don't set HA_CREATE_USED_ENGINE
-
- 17 Nov, 2009 1 commit
-
-
Mattias Jonsson authored
sql/sql_partition.cc: Bug#45904 Used list_of_part_fields instead of list_of_subpart_fields to discover if KEY subpartitioning => caused failure when charset=utf8 even for subpartitioning by key, would also allow for subpartitioning by hash with utf8 erroneously
-
- 09 Nov, 2009 1 commit
-
-
Mattias Jonsson authored
Bug when setting up default partitioning, used an uninitialized variabe. mysql-test/r/partition.result: Bug#48276: can't add column if subpartition exists Added result mysql-test/t/partition.test: Bug#48276: can't add column if subpartition exists Added test sql/sql_partition.cc: Bug#48276: can't add column if subpartition exists even if is_create_table_ind was set, one tried to set no_subparts with the unitialized no_parts local variable. Fixed by rearrange the code to be to only execute the statements when is_create_table_ind was not set.
-
- 03 Nov, 2009 1 commit
-
-
Mattias Jonsson authored
ONLY_FULL_GROUP_BY Problem was that during checking and preparation of the partitioining function as a side effect in fix_fields the full_group_by_flag was changed. Solution was to set it back to its original value after calling fix_fields. Updated patch, to also exclude allow_sum_func from being affected of fix_fields, as requested by reviewer. mysql-test/r/partition.result: Bug#46923: select count(*) from partitioned table fails with ONLY_FULL_GROUP_BY Updated result file mysql-test/t/partition.test: Bug#46923: select count(*) from partitioned table fails with ONLY_FULL_GROUP_BY Extended test case to cover this bug sql/sql_partition.cc: Bug#46923: select count(*) from partitioned table fails with ONLY_FULL_GROUP_BY Resetting full_group_by_flag and allow_sum_func back to their original values, not conflicting with the sql_mode 'ONLY_FULL_GROUP_BY'
-
- 21 Oct, 2009 1 commit
-
-
Mikael Ronstrom authored
-
- 08 Oct, 2009 1 commit
-
-
Mattias Jonsson authored
backport for bug#44059 from mysql-pe to mysql-5.1-bugteam Using the partition with most rows instead of first partition to estimate the cardinality of indexes. mysql-test/r/partition.result: Bug#44059: Incorrect cardinality of indexes on a partitioned table Added test result mysql-test/t/partition.test: Bug#44059: Incorrect cardinality of indexes on a partitioned table Added test case sql/ha_partition.cc: Bug#44059: Incorrect cardinality of indexes on a partitioned table Checking which partition that has the most rows, and using that partition for HA_STATUS_CONST instead of first partition
-
- 10 Sep, 2009 1 commit
-
-
Marc Alff authored
WL#2265 (RESIGNAL) Manual merge of SIGNAL and RESIGNAL to mysql-trunk-signal, plus required dependencies.
-
- 21 Aug, 2009 1 commit
-
-
Mattias Jonsson authored
INSERT ... SELECT ... Problem was that when bulk insert is used on an empty table/partition, it disables the indexes for better performance, but in this specific case it also tries to read from that partition using an index, which is not possible since it has been disabled. Solution was to allow index reads on disabled indexes if there are no records. Also reverted the patch for bug#38005, since that was a workaround in the partitioning engine instead of a fix in myisam. mysql-test/r/partition.result: Bug#46639: 1030 (HY000): Got error 124 from storage engine on INSERT ... SELECT ... updated result file mysql-test/t/partition.test: Bug#46639: 1030 (HY000): Got error 124 from storage engine on INSERT ... SELECT ... Added testcase sql/ha_partition.cc: Bug#46639: 1030 (HY000): Got error 124 from storage engine on INSERT ... SELECT ... reverted the patch for bug#38005, since that was a workaround around this problem, not needed after fixing it in myisam. storage/myisam/mi_search.c: Bug#46639: 1030 (HY000): Got error 124 from storage engine on INSERT ... SELECT ... Return HA_ERR_END_OF_FILE instead of HA_ERR_WRONG_INDEX when there are no rows.
-
- 06 Aug, 2009 2 commits
-
-
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.
-
Satya B authored
column on partitioned table An assertion 'ASSERT_COULUMN_MARKED_FOR_READ' is failed if the query is executed with index containing double column on partitioned table. The problem is that assertion expects all the fields which are read, to be in the read_set. In this query only the field 'a' is in the readset as the tables in the query are joined by the field 'a' and so the assertion fails expecting other field 'b'. Since the function cmp() is just comparison of two parameters passed, the assertion is not required. Fixed by removing the assertion in the double fields comparision function and also fixed the index initialization to do ordered index scan with RW LOCK which ensures all the fields from a key are in the read_set. Note: this bug is not reproducible with other datatypes because the assertion doesn't exist in comparision function for other datatypes. mysql-test/r/partition.result: Testcase for BUG#45816 mysql-test/t/partition.test: Testcase for BUG#45816 sql/field.cc: Removed the assertion ASSERT_COLUMN_MARED_FOR_READ in Field_double::cmp() function sql/ha_partition.cc: Fixed index_int() method to make it initialize the read_set properly if ordered index scan with RW lock is requested.
-
- 31 Jul, 2009 1 commit
-
-
Davi Arnaut authored
engine to the partition_csv test. Also remove test case that was duplicated. Fix connection procedure with the embedded server. mysql-test/r/partition.result: Update test case result. mysql-test/r/partition_csv.result: Update test case result. mysql-test/t/partition.test: Move test cases to the partition_csv test. mysql-test/t/partition_csv.test: Move tests from partition.test and remove duplicate. Tweaky connection procedure to work with embedded.
-