- 06 Jul, 2009 1 commit
-
-
Ramil Kalimullin authored
-
- 03 Jul, 2009 13 commits
-
-
Kristofer Pettersson authored
-
Kristofer Pettersson authored
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.
-
Alexey Kopytov authored
-
Alexey Kopytov authored
-
Sergey Glukhov authored
-
Sergey Glukhov authored
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.
-
Bernt M. Johnsen authored
-
Sergey Glukhov authored
enabled message storing into error message list for 'drop table' command
-
Bernt M. Johnsen authored
-
Bernt M. Johnsen authored
-
Bernt M. Johnsen authored
-
Bernt M. Johnsen authored
-
Alexey Kopytov authored
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.
-
- 02 Jul, 2009 4 commits
-
-
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().
-
Matthias Leich authored
-
Matthias Leich authored
Details: - Add "sync_slave_with_master" at test end - Restore the initial value of log_bin_trust_function_creators
-
V Narayanan authored
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.
-
- 01 Jul, 2009 4 commits
-
-
Staale Smedseng authored
-
Staale Smedseng authored
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.
-
Satya B authored
-
Satya B authored
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.
-
- 30 Jun, 2009 2 commits
-
-
Luis Soares authored
-
Davi Arnaut authored
Add new header to Makefile.am so it gets bundled.
-
- 29 Jun, 2009 10 commits
-
-
Staale Smedseng authored
-
Staale Smedseng authored
-
Satya B authored
-
Satya B authored
-
Christoffer Hall authored
-
Christoffer Hall authored
-
Satya B authored
-
Satya B authored
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.
-
Luis Soares authored
-
V Narayanan authored
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.
-
- 27 Jun, 2009 1 commit
-
-
Luis Soares authored
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.
-
- 26 Jun, 2009 5 commits
-
-
Evgeny Potemkin authored
-
Evgeny Potemkin authored
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.
-
Alexey Kopytov authored
-
Alexey Kopytov authored
-
Staale Smedseng authored
-