summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* BUG#44581 Slave stops when transaction with non-transactional table gets ↵Alfranio Correia2009-07-066-24/+302
| | | | | | | | | | | | | | | | | | | | | lock wait timeout In STMT and MIXED modes, a statement that changes both non-transactional and transactional tables must be written to the binary log whenever there are changes to non-transactional tables. This means that the statement gets into the binary log even when the changes to the transactional tables fail. In particular , in the presence of a failure such statement is annotated with the error number and wrapped in a begin/rollback. On the slave, while applying the statement, it is expected the same failure and the rollback prevents the transactional changes to be persisted. Unfortunately, statements that fail due to concurrency issues (e.g. deadlocks, timeouts) are logged in the same way causing the slave to stop as the statements are applied sequentially by the SQL Thread. To fix this bug, we automatically ignore concurrency failures on the slave. Specifically, the following failures are ignored: ER_LOCK_WAIT_TIMEOUT, ER_LOCK_DEADLOCK and ER_XA_RBDEADLOCK.
* 5.0-bugteam -> 5.1-bugteamKristofer Pettersson2009-07-031-31/+32
|\
| * Bug#37274 client 'status' command doesn't print all info after losing ↵Kristofer Pettersson2009-07-031-31/+32
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | connection to server If the server connection was lost during repeated status commands, the client would fail to detect this and the client output would be inconsistent. This patch fixes this issue by making sure that the server is online before the client attempts to execute the status command. client/mysql.cc: * Replace variable "connected" with a call to mysql_real_query_for_lazy() will attempt to reconnect to server on if there is a failure.
* | Automerge.Alexey Kopytov2009-07-039-51/+204
|\ \
| * \ Manual merge.Alexey Kopytov2009-07-039-51/+204
| |\ \
| | * | Bug #45262: Bad effects with CREATE TABLE and DECIMAL Alexey Kopytov2009-07-039-51/+205
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Using DECIMAL constants with more than 65 digits in CREATE TABLE ... SELECT led to bogus errors in release builds or assertion failures in debug builds. The problem was in inconsistency in how DECIMAL constants and fields are handled internally. We allow arbitrarily long DECIMAL constants, whereas DECIMAL(M,D) columns are limited to M<=65 and D<=30. my_decimal_precision_to_length() was used in both Item and Field code and truncated precision to DECIMAL_MAX_PRECISION when calculating value length without adjusting precision and decimals. As a result, a DECIMAL constant with more than 65 digits ended up having length less than precision or decimals which led to assertion failures. Fixed by modifying my_decimal_precision_to_length() so that precision is truncated to DECIMAL_MAX_PRECISION only for Field object which is indicated by the new 'truncate' parameter. Another inconsistency fixed by this patch is how DECIMAL constants and expressions are handled for CREATE ... SELECT. create_tmp_field_from_item() (which is used for constants) was changed as a part of the bugfix for bug #24907 to handle long DECIMAL constants gracefully. Item_func::tmp_table_field() (which is used for expressions) on the other hand was still using a simplistic approach when creating a Field_new_decimal from a DECIMAL expression. mysql-test/r/type_newdecimal.result: Added a test case for bug #45262. mysql-test/t/type_newdecimal.test: Added a test case for bug #45262. sql/item.cc: Use the new 'truncate' parameter in my_decimal_precision_to_length(). sql/item_cmpfunc.cc: Use the new 'truncate' parameter in my_decimal_precision_to_length(). sql/item_func.cc: 1. Use the new 'truncate' parameter in my_decimal_precision_to_length(). 2. Do not truncate decimal precision to DECIMAL_MAX_PRECISION for additive expressions involving long DECIMAL constants. 3. Fixed an incosistency in how DECIMAL constants and expressions are handled for CREATE ... SELECT. sql/item_func.h: Use the new 'truncate' parameter in my_decimal_precision_to_length(). sql/item_sum.cc: Use the new 'truncate' parameter in my_decimal_precision_to_length(). sql/my_decimal.h: Do not truncate precision to DECIMAL_MAX_PRECISION when calculating length in my_decimal_precision_to_length() if 'truncate' parameter is FALSE. sql/sql_select.cc: 1. Use the new 'truncate' parameter in my_decimal_precision_to_length(). 2. Use a more correct logic when adjusting value's length.
* | | | 5.0-bugteam->5.1-bugteam mergeSergey Glukhov2009-07-033-3/+172
|\ \ \ \
| * | | | Bug#45806 crash when replacing into a view with a join!Sergey Glukhov2009-07-033-3/+172
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The crash happend because for views which are joins we have table_list->table == 0 and table_list->table->'any method' call leads to crash. The fix is to perform table_list->table->file->extra() method for all tables belonging to view. mysql-test/r/view.result: test result mysql-test/t/view.test: test case sql/sql_insert.cc: added prepare_for_positional_update() function which updates extra info about primary key for tables belonging to view.
| * | | | Prepare for pushBernt M. Johnsen2009-07-032-32/+13
| |\ \ \ \
* | | | | | Bug#42364 SHOW ERRORS returns empty resultset after dropping non existent tableSergey Glukhov2009-07-034-1/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | enabled message storing into error message list for 'drop table' command mysql-test/r/warnings.result: test result mysql-test/t/warnings.test: test case sql/sql_table.cc: We should skip error sending then we should return warnings to client as some functions may send its own errors, so we should set no_warnings_for_error= 0 only in case of warning. The fix is to enable message storing into error message list for 'drop table' command(only for error case). tests/mysql_client_test.c: test fix
* | | | | | automergeBernt M. Johnsen2009-07-035-4/+42
|\ \ \ \ \ \ | | |_|_|_|/ | |/| | | |
| * | | | | Bug #45807: crash accessing partitioned table and sql_modeGeorgi Kodinov2009-07-024-4/+39
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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(). mysql-test/r/partition.result: Bug #45807: test case mysql-test/t/partition.test: Bug #45807: test case sql/item.cc: Bug #45807: fix the ONLY_FULL_GROUP_BY check code to handle correctly non-cacheable tables. sql/sql_partition.cc: Bug #45807: fix the Item::fix_fields() context initializatio for the partitioning expression in CREATE TABLE.
| * | | | | Merge 5.0 -> 5.1 of fix for bug 45902Matthias Leich2009-07-021-0/+3
| |\ \ \ \ \ | | |/ / / /
| | * | | | Fix for Bug#45902 rpl_sp fails sporadically in check testcasesMatthias Leich2009-07-022-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Details: - Add "sync_slave_with_master" at test end - Restore the initial value of log_bin_trust_function_creators
* | | | | | Prepare for pushBernt M. Johnsen2009-07-032-32/+13
|\ \ \ \ \ \ | |/ / / / / |/| | | | |
| * | | | | Bug#15866 Prepared for push on 5.1Bernt M. Johnsen2009-07-032-32/+13
| |\ \ \ \ \ |/ / / / / / | | | _ / / | | | / /
| * | | | Bug#15866 Prepared for push on 5.0Bernt M. Johnsen2009-07-032-32/+13
| |/ / /
* | | | Bug#45793 macce charset causes error with IBMDB2IV Narayanan2009-07-023-0/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Creating an IBMDB2I table with the macce character set is successful, but any attempt to insert data into the table was failing. This was happening because the character set name "macce" is not a valid iconv descriptor for IBM i PASE. This patch adds an override to convertTextDesc to use the equivalent valid iconv descriptor "IBM-1282" instead. mysql-test/suite/ibmdb2i/r/ibmdb2i_bug_45793.result: Bug#45793 macce charset causes error with IBMDB2I Result file for the test case. mysql-test/suite/ibmdb2i/t/ibmdb2i_bug_45793.test: Bug#45793 macce charset causes error with IBMDB2I Add a testcase for the macce charater set. storage/ibmdb2i/db2i_charsetSupport.cc: Bug#45793 macce charset causes error with IBMDB2I The character set name "macce" is not a valid iconv descriptor for IBM i PASE. Add an override to convertTextDesc to use the equivalent valid iconv descriptor "IBM-1282" instead.
* | | | Merge from 5.0Staale Smedseng2009-07-011-2/+2
|\ \ \ \ | |/ / /
| * | | Bug #45790 Potential DoS vector: Writing of user input to logStaale Smedseng2009-07-012-2/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | without proper formatting The problem is that a suitably crafted database identifier supplied to COM_CREATE_DB or COM_DROP_DB can cause a SIGSEGV, and thereby a denial of service. The database name is printed to the log without using a format string, so potential attackers can control the behavior of my_b_vprintf() by supplying their own format string. A CREATE or DROP privilege would be required. This patch supplies a format string to the printing of the database name. A test case is added to mysql_client_test. sql/sql_parse.cc: Added format strings. tests/mysql_client_test.c: Added new test case.
* | | | merge to 5.1-bugteamSatya B2009-07-015-2/+243
|\ \ \ \
| * \ \ \ merge: 5.1-bt bug branch --> 5.1-bt latestLuis Soares2009-06-304-1/+242
| |\ \ \ \
| | * | | | BUG#42941: --database paramater to mysqlbinlog fails with RBRLuis Soares2009-06-074-1/+242
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | mysqlbinlog --database parameter was being ignored when processing row events. As such no event filtering would take place. This patch addresses this by deploying a call to shall_skip_database when table_map_events are handled (as these contain also the name of the database). All other rows events referencing the table id for the filtered map event, will also be skipped. client/mysqlbinlog.cc: Added shall_skip_database call to the part of the code that handles Table_map_log_events. It inspects the database name and decides whether to filter the event or not. Furthermore, if table map event is filtered next events referencing the table id in the table map event, will also be filtered. mysql-test/suite/binlog/t/binlog_row_mysqlbinlog_db_filter.test: Test case that checks if row events are actually filtered out. sql/log_event.h: Added a map for holding the currently ignored table map events. Table map events are inserted when they shall be skipped and removed once the last row event in the statement is processed.
| * | | | | Post-merge fix for Innodb snapshot.Davi Arnaut2009-06-301-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add new header to Makefile.am so it gets bundled. storage/innobase/Makefile.am: Add header so it becomes part of a source distribution.
* | | | | | Fix build failure after applying Innodb snapshot 5.1-ss5282Satya B2009-07-011-1/+2
|/ / / / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | After applying Innodb snapshot 5.1-ss5282, build was broken because of missing header file. Adding the header file to Makefile.am after informing the innodb developers.
* | | | | Merge from 5.0Staale Smedseng2009-06-2936-216/+246
|\ \ \ \ \ | | |/ / / | |/| | |
| * | | | Merge from 5.0-btStaale Smedseng2009-06-2940-224/+254
| | | | |
* | | | | merge to mysql-5.1-bugteam branchSatya B2009-06-291-1/+2
|\ \ \ \ \
| * \ \ \ \ Merge from team treeChristoffer Hall2009-06-294-1/+107
| |\ \ \ \ \
| * \ \ \ \ \ Merge from main branchChristoffer Hall2009-06-2956-1145/+768
| |\ \ \ \ \ \
| * | | | | | | BUG#42721 configure.in invokes 'nm' directlyChristoffer Hall2009-06-221-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A hardcoded use of nm and libc was put into configure.in. This broke cross-compiling and is bad practice. Fitting variables now used.
* | | | | | | | merge to mysql-5.1-bugteamSatya B2009-06-297-67/+141
|\ \ \ \ \ \ \ \ | |_|_|/ / / / / |/| | | | | | |
| * | | | | | | Applying InnoDB snashot 5.1-ss5282, Add TestCase for BUG#40565Satya B2009-06-112-0/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Merge the test case from 5.0 to 5.1 for BUG#40565 Detailed revision comments: r5233 | marko | 2009-06-03 15:12:44 +0300 (Wed, 03 Jun 2009) | 11 lines branches/5.1: Merge the test case from r5232 from branches/5.0: ------------------------------------------------------------------------ r5232 | marko | 2009-06-03 14:31:04 +0300 (Wed, 03 Jun 2009) | 21 lines branches/5.0: Merge r3590 from branches/5.1 in order to fix Bug #40565 (Update Query Results in "1 Row Affected" But Should Be "Zero Rows"). Also, add a test case for Bug #40565. rb://128 approved by Heikki Tuuri ------------------------------------------------------------------------
| * | | | | | | Applying InnoDB snashot 5.1-ss5282, Fix for BUG#45097Satya B2009-06-113-7/+31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | BUG#45097 - Hang during recovery, redo logs for doublewrite buffer pages Detailed revision comments: r5128 | vasil | 2009-05-26 17:26:37 +0300 (Tue, 26 May 2009) | 7 lines branches/5.1: Fix Bug#45097 Hang during recovery, redo logs for doublewrite buffer pages Do not write redo log for the pages in the doublewrite buffer. Also, do not make a dummy change to the page because this is not needed. r5150 | vasil | 2009-05-27 18:56:03 +0300 (Wed, 27 May 2009) | 4 lines branches/5.1: Whitespace fixup.
| * | | | | | | Applying InnoDB snashot 5.1-ss5282, PRE-Fix for BUG#45097Satya B2009-06-113-60/+91
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | BUG#45097 - Hang during recovery, redo logs for doublewrite buffer pages Detailed revision comments: r5126 | vasil | 2009-05-26 16:57:12 +0300 (Tue, 26 May 2009) | 9 lines branches/5.1: Preparation for the fix of Bug#45097 Hang during recovery, redo logs for doublewrite buffer pages Non-functional change: move FSP_* macros from fsp0fsp.h to a new file fsp0types.h. This is needed in order to be able to use FSP_EXTENT_SIZE in mtr0log.ic. r5127 | vasil | 2009-05-26 17:05:43 +0300 (Tue, 26 May 2009) | 9 lines branches/5.1: Preparation for the fix of Bug#45097 Hang during recovery, redo logs for doublewrite buffer pages Do not include unnecessary headers mtr0log.h and fut0lst.h in trx0sys.h and include fsp0fsp.h just before it is needed. This is needed in order to be able to use TRX_SYS_SPACE in mtr0log.ic.
* | | | | | | | Null merge mysql-5.0-bugteam to mysql-5.1-bugteamSatya B2009-06-290-0/+0
|\ \ \ \ \ \ \ \ | | |_|_|/ / / / | |/| | | | | |
| * | | | | | | Additional Fix for BUG#40565 - Update Query Results in "1 Row Affected" Satya B2009-06-291-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | But Should Be "Zero Rows" After applying the innodb snapshot 5.0-ss5406 for bug#40565, the windows push build tests failed because of the missing cast of void * pointer in row0sel.c file Informed the innodb developers and received patch by email. innobase/row/row0sel.c: Cast the default_rec which is a void * pointer
* | | | | | | | merge: 5.1-bt bug branch --> 5.1-bt latestLuis Soares2009-06-294-1/+107
|\ \ \ \ \ \ \ \ | |_|_|_|/ / / / |/| | | | | | |
| * | | | | | | BUG#42851: Spurious "Statement is not safe to log in statementLuis Soares2009-06-274-1/+107
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | format." warnings Despite the fact that a statement would be filtered out from binlog, a warning would still be thrown if it was issued with the LIMIT. This patch addresses this issue by checking the filtering rules before printing out the warning. mysql-test/suite/binlog/t/binlog_stm_unsafe_warning-master.opt: Parameter to filter out database: "b42851". mysql-test/suite/binlog/t/binlog_stm_unsafe_warning.test: Added a new test case. sql/sql_class.cc: Added filtering rules check to condition used to decide whether to printout warning or not.
* | | | | | | | Bug#45196 Some collations do not sort correctly with IBMDB2IV Narayanan2009-06-293-9/+64
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Some collations--including cp1250_czech_cs,latin2_czech_cs, ucs2/utf8_czech_ci, ucs2/utf8_danish_ci--are not being sorted correctly by the IBMDB2I storage engine. This was being caused because the sort order used by DB2 is incompatible with the order expected by MySQL. This patch removes support for the cp1250_czech_cs and latin2_czech_cs collations because it has been determined that the sort order used by DB2 is incompatible with the order expected by MySQL. Users needing a czech collation with IBMDB2I are encouraged to use a Unicode-based collation instead of these single-byte collations. This patch also modifies the DB2 sort sequence used for ucs2/utf8_czech_ci and ucs2/utf8_danish_ci collations to better match the sorting expected by MySQL. This will only affect indexes or tables that are newly created through the IBMDB2I storage engine. Existing IBMDB2I tables will retain the old sort sequence until recreated. mysql-test/suite/ibmdb2i/r/ibmdb2i_bug_45196.result: Bug#45196 Some collations do not sort correctly with IBMDB2I Result file for the test case. mysql-test/suite/ibmdb2i/t/ibmdb2i_bug_45196.test: Bug#45196 Some collations do not sort correctly with IBMDB2I Adding tests for testing the sort order with the modified collations. storage/ibmdb2i/db2i_collationSupport.cc: Bug#45196 Some collations do not sort correctly with IBMDB2I Remove the support for the cp1250_czech_cs and latin2_czech_cs collations because it has been determined that the sort order used by DB2 is incompatible with the order expected by MySQL. Users needing a czech collation with IBMDB2I are encouraged to use a Unicode-based collation instead of these single-byte collations. This patch also modifies the DB2 sort sequence used for ucs2/utf8_czech_ci and ucs2/utf8_danish_ci collations to better match the sorting expected by MySQL. This will only affect indexes or tables that are newly created through the IBMDB2I storage engine. Existing IBMDB2I tables will retain the old sort sequence until recreated.
* | | | | | | | Merged bug#45266.Evgeny Potemkin2009-06-265-1/+170
|\ \ \ \ \ \ \ \ | |/ / / / / / / |/| | | | | | |
| * | | | | | | Bug#45266: Uninitialized variable lead to an empty result.Evgeny Potemkin2009-06-265-1/+170
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The TABLE::reginfo.impossible_range is used by the optimizer to indicate that the condition applied to the table is impossible. It wasn't initialized at table opening and this might lead to an empty result on complex queries: a query might set the impossible_range flag on a table and when the query finishes, all tables are returned back to the table cache. The next query that uses the table with the impossible_range flag set and an index over the table will see the flag and thus return an empty result. The open_table function now initializes the TABLE::reginfo.impossible_range variable. mysql-test/r/select.result: A test case for the bug#45266: Uninitialized variable lead to an empty result. mysql-test/t/select.test: A test case for the bug#45266: Uninitialized variable lead to an empty result. sql/sql_base.cc: Bug#45266: Uninitialized variable lead to an empty result. The open_table function now initializes the TABLE::reginfo.impossible_range variable. sql/sql_select.cc: Bug#45266: Uninitialized variable lead to an empty result. The open_table function now initializes the TABLE::reginfo.impossible_range variable. sql/structs.h: Bug#45266: Uninitialized variable lead to an empty result. A comment is added.
* | | | | | | | Bug#45548: XA transaction without access to InnoDB tables crashes the serverDavi Arnaut2009-06-253-2/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The problem is that the one phase commit function failed to properly end a empty transaction. The solution is to ensure that the transaction cleanup procedure is invoked even for empty transactions. mysql-test/r/xa.result: Add test case result for Bug#45548 mysql-test/t/xa.test: Add test case for Bug#45548 sql/handler.cc: Invoke transaction cleanup function whenever a transaction is ended.
* | | | | | | | Automerge.Alexey Kopytov2009-06-260-0/+0
|\ \ \ \ \ \ \ \ | | |/ / / / / / | |/| | | | | |
| * | | | | | | Automerge.Alexey Kopytov2009-06-261-4/+18
| |\ \ \ \ \ \ \
* | \ \ \ \ \ \ \ Automerge.Alexey Kopytov2009-06-261-4/+18
|\ \ \ \ \ \ \ \ \
| * \ \ \ \ \ \ \ \ Automerge.Alexey Kopytov2009-06-261-4/+18
| |\ \ \ \ \ \ \ \ \ | | | |/ / / / / / / | | |/| | | | | | |
| | * | | | | | | | Bug #41710: MySQL 5.1.30 crashes on the latest OpenSolaris 10 Alexey Kopytov2009-06-181-4/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Change the default optimization level for Sun Studio to "-O1". This is a workaround for a Sun Studio bug (see bug #41710 comments for details): 1. Use $GCC instead of $ac_cv_prog_gcc to check for gcc, since the first one is the only documented way to do it. 2. Use $GXX instead of $ac_cv_prog_cxx_g to check for g++, since the latter is set to "yes" when the C++ compiler accepts "-g" which is the case for both g++ and CC. 3. When building with Sun Studio, set the default values for CFLAGS/CXXFLAGS to "-O1", since unlike GCC, Sun Studio interprets "-O" as "-xO3" (see the manual pages for cc and CC). configure.in: 1. Use $GCC instead of $ac_cv_prog_gcc to check for gcc, since the first one is the only documented way to do it. 2. Use $GXX instead of $ac_cv_prog_cxx_g to check for g++, since the latter is set to "yes" when the C++ compiler accepts "-g" which is the case for both g++ and CC. 3. When building with Sun Studio, set the default values for CFLAGS/CXXFLAGS to "-O1", since unlike GCC, Sun Studio interprets "-O" as "-xO3" (see the manual pages for cc and CC).
* | | | | | | | | | local merge: 5.1-bt bug branch --> 5.1-bt latestLuis Soares2009-06-262-2/+25
|\ \ \ \ \ \ \ \ \ \ | |_|_|_|/ / / / / / |/| | | | | | | | |
| * | | | | | | | | BUG#44270: Post-push fixLuis Soares2009-06-262-2/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The test case added failed sporadically on PB. This is due to the fact that the user thread in some cases is waiting for slave IO to stop and then check the error number. Thence, sometimes the user thread would race for the error number with IO thread. This post push fix addresses this by replacing the wait for slave io to stop with a wait for slave io error (as it seems it was added in 6.0 also after patch on which this is based was pushed). This implied backporting wait_for_slave_io_error.inc from 6.0 also.