- 16 Dec, 2010 2 commits
-
-
Martin Hansson authored
-
Martin Hansson authored
file .\item_subselect.cc, line 836 IN quantified predicates are never executed directly. They are rather wrapped inside nodes called IN Optimizers (Item_in_optimizer) which take care of the execution. However, this is not done during query preparation. Unfortunately the LIKE predicate pre-evaluates constant right-hand side arguments even during name resolution. Likely this is meant as an optimization. Fixed by not pre-evaluating LIKE arguments in view prepare mode. Back-ported to 5.0s
-
- 15 Dec, 2010 1 commit
-
-
Alexander Nozdrin authored
The user-visible problem was that changes to column-level privileges, happened in between of PREPARE and EXECUTE of a prepared statement, were neglected. I.e. a prepared statement could be executed with the column-level privileges as of PREPARE-time. The problem existed for column-level privileges only. A similar problem existed for stored programs: the changes between executions didn't have an effect. Technically the thing is that table references are cached in Prepared_statement::prepare() call. In subsequent Prepared_statement::execute() calls those cached values are used. There are two functions to get a field by name: find_field_in_table() and find_field_in_table_ref(). On prepare-phase find_field_in_table_ref() is called, on execute-phase -- find_field_in_table() because the table is cached. find_field_in_table() does not check column-level privileges and expects the caller to do that. The problem was that this check was forgotten. The fix is to check them there as it happens in find_field_in_table_ref().
-
- 08 Dec, 2010 1 commit
-
-
Georgi Kodinov authored
-
- 03 Dec, 2010 1 commit
-
-
Georgi Kodinov authored
-
- 24 Nov, 2010 4 commits
-
-
Gleb Shchepa authored
> revision-id: gshchepa@mysql.com-20100801181236-uyuq6ewaq43rw780 > parent: alexey.kopytov@sun.com-20100723115254-jjwmhq97b9wl932l > committer: Gleb Shchepa <gshchepa@mysql.com> > branch nick: mysql-5.1-security > timestamp: Sun 2010-08-01 22:12:36 +0400 > Bug #54461: crash with longblob and union or update with subquery > > Queries may crash, if > 1) the GREATEST or the LEAST function has a mixed list of > numeric and LONGBLOB arguments and > 2) the result of such a function goes through an intermediate > temporary table. > > An Item that references a LONGBLOB field has max_length of > UINT_MAX32 == (2^32 - 1). > > The current implementation of GREATEST/LEAST returns REAL > result for a mixed list of numeric and string arguments (that > contradicts with the current documentation, this contradiction > was discussed and it was decided to update the documentation). > > The max_length of such a function call was calculated as a > maximum of argument max_length values (i.e. UINT_MAX32). > > That max_length value of UINT_MAX32 was used as a length for > the intermediate temporary table Field_double to hold > GREATEST/LEAST function result. > > The Field_double::val_str() method call on that field > allocates a String value. > > Since an allocation of String reserves an additional byte > for a zero-termination, the size of String buffer was > set to (UINT_MAX32 + 1), that caused an integer overflow: > actually, an empty buffer of size 0 was allocated. > > An initialization of the "first" byte of that zero-size > buffer with '\0' caused a crash. > > The Item_func_min_max::fix_length_and_dec() has been > modified to calculate max_length for the REAL result like > we do it for arithmetical operators. mysql-test/r/func_misc.result: Test case for bug #54461. mysql-test/t/func_misc.test: Test case for bug #54461. sql/item_func.cc: Bug #54461: crash with longblob and union or update with subquery The Item_func_min_max::fix_length_and_dec() has been modified to calculate max_length for the REAL result like we do it for arithmetical operators.
-
Alexander Nozdrin authored
Fix formatting issues in README file.
-
Alexander Nozdrin authored
-
Alexander Nozdrin authored
EXCEPTIONS-CLIENT from all the places.
-
- 23 Nov, 2010 1 commit
-
-
Ramil Kalimullin authored
-
- 22 Nov, 2010 3 commits
-
-
Gleb Shchepa authored
> revision-id: alexey.kopytov@sun.com-20100824103548-ikm79qlfrvggyj9h > parent: sunny.bains@oracle.com-20100816001222-xqc447tr6jwh8c53 > committer: Alexey Kopytov <Alexey.Kopytov@Sun.com> > branch nick: 5.1-security > timestamp: Tue 2010-08-24 14:35:48 +0400 > message: > Bug #55568: user variable assignments crash server when used > within query > > The server could crash after materializing a derived table > which requires a temporary table for grouping. > > When destroying the temporary table used to execute a query for > a derived table, JOIN::destroy() did not clean up Item_fields > pointing to fields in the temporary table. This led to > dereferencing a dangling pointer when printing out the items > tree later in the outer SELECT. > > The solution is an addendum to the patch for bug37362: in > addition to cleaning up items in tmp_all_fields3, do the same > for items in tmp_all_fields1, since now we have an example > where this is necessary. sql/field.cc: Make sure field->table_name is not set to NULL in Field::make_field() to avoid assertion failure in Item_field::make_field() after cleaning up items (the assertion fired in udf.test when running the test suite with the patch applied). sql/sql_select.cc: In addition to cleaning up items in tmp_all_fields3, do the same for items in tmp_all_fields1. Introduce a new helper function to avoid code duplication. sql/sql_select.h: Introduce a new helper function to avoid code duplication in JOIN::destroy().
-
Alexander Nozdrin authored
-
Alexander Nozdrin authored
-
- 08 Nov, 2010 2 commits
-
-
Sergey Glukhov authored
backport from 5.1 mysql-test/r/subselect.result: backport from 5.1 mysql-test/t/subselect.test: backport from 5.1 sql/sql_select.cc: backport from 5.1
-
Sergey Glukhov authored
Problem: a flaw (derefencing a NULL pointer) in the LIKE optimization code may lead to a server crash in some rare cases. Fix: check the pointer before its dereferencing. mysql-test/r/func_like.result: Fix for bug #54575: crash when joining tables with unique set column - test result. mysql-test/t/func_like.test: Fix for bug #54575: crash when joining tables with unique set column - test case. sql/item_cmpfunc.cc: Fix for bug #54575: crash when joining tables with unique set column - check res2 buffer pointer before its dereferencing as it may be NULL in some cases.
-
- 29 Oct, 2010 1 commit
-
-
Georgi Kodinov authored
-
- 05 Oct, 2010 4 commits
-
-
Georgi Kodinov authored
-
Georgi Kodinov authored
-
Georgi Kodinov authored
-
Georgi Kodinov authored
-
- 20 Aug, 2010 2 commits
-
-
Georgi Kodinov authored
-
Georgi Kodinov authored
-
- 10 Aug, 2010 1 commit
-
-
Georgi Kodinov authored
Updated the README file.
-
- 02 Aug, 2010 2 commits
-
-
Georgi Kodinov authored
-
Georgi Kodinov authored
-
- 30 Jul, 2010 1 commit
-
-
Davi Arnaut authored
Fix a regression (due to a typo) which caused spurious incorrect argument errors for long data stream parameters if all forms of logging were disabled (binary, general and slow logs). sql/sql_prepare.cc: Add a missing logical NOT operator.
-
- 21 Jul, 2010 2 commits
-
-
Georgi Kodinov authored
-
Georgi Kodinov authored
-
- 15 Jul, 2010 1 commit
-
-
Alexey Kopytov authored
Calculating the estimated number of records for a range scan may take a significant time, and it was impossible for a user to interrupt that process by killing the connection or the query. Fixed by checking the thread's 'killed' status in check_quick_keys() and interrupting the calculation process if it is set to a non-zero value.
-
- 07 Jul, 2010 1 commit
-
-
Vasil Dimov authored
(without the unrelated whitespace changes): ------------------------------------------------------------------------ r7009 | jyang | 2010-04-29 20:44:56 +0300 (Thu, 29 Apr 2010) | 6 lines branches/5.0: Port fix for bug #49238 (Creating/Dropping a temporary table while at 1023 transactions will cause assert) from 5.1 to branches/5.1. Separate action for return value DB_TOO_MANY_CONCURRENT_TRXS from that of DB_MUST_GET_MORE_FILE_SPACE in row_drop_table_for_mysql(). ------------------------------------------------------------------------
-
- 02 Jul, 2010 3 commits
-
-
Georgi Kodinov authored
-
Georgi Kodinov authored
-
Georgi Kodinov authored
-
- 28 Jun, 2010 1 commit
-
-
Davi Arnaut authored
The problem was that a user could supply supply data in chunks via the COM_STMT_SEND_LONG_DATA command to prepared statement parameter other than of type TEXT or BLOB. This posed a problem since other parameter types aren't setup to handle long data, which would lead to a crash when attempting to use the supplied data. Given that long data can be supplied at any stage of a prepared statement, coupled with the fact that the type of a parameter marker might change between consecutive executions, the solution is to validate at execution time each parameter marker for which a data stream was provided. If the parameter type is not TEXT or BLOB (that is, if the type is not able to handle a data stream), a error is returned. sql/sql_prepare.cc: Before converting the parameter data stream, check the type compatibility. tests/mysql_client_test.c: Add test case.
-
- 21 Jun, 2010 2 commits
-
-
Georgi Kodinov authored
-
Georgi Kodinov authored
-
- 17 Jun, 2010 1 commit
-
-
Joerg Bruehe authored
line exceeds the limit The number and/or names of our files for the main test suite (contents of "mysql-test/t/") now exceeds the command line length limit on AIX. Solve the problem by using separate "cp" commands for the various file name extensions.
-
- 15 Jun, 2010 1 commit
-
-
Bjorn Munch authored
Reorder code breaks when finding tests skipped due to --skip-rpl etc. Add simple test that master_opt is non-empty
-
- 14 Jun, 2010 1 commit
-
-
Bjorn Munch authored
Kill mysqltest and call mtr_kill_leftovers() before terminating
-
- 10 Jun, 2010 1 commit
-
-
Davi Arnaut authored
Addendum: Work around a compilation failure on Windows due to windows.h not being added to the global namespace. extra/yassl/include/lock.hpp: Move windows.h inclusion into the global namespace.
-