- 01 Apr, 2009 1 commit
-
-
Georgi Kodinov authored
-
- 30 Mar, 2009 1 commit
-
-
Matthias Leich authored
-
- 27 Mar, 2009 8 commits
-
-
Georgi Kodinov authored
-
Georgi Kodinov authored
-
Staale Smedseng authored
-
Alexey Kopytov authored
-
Staale Smedseng authored
updates Attempt to execute trigger or stored function with multi-UPDATE which used - but didn't update - a table that was also used by the calling statement led to an error. Read-only reference to tables used in the calling statement should be allowed. This problem was caused by the fact that check for conflicting use of tables in SP/triggers was performed in open_tables(), and in case of multi-UPDATE we didn't know exact lock type at this stage. We solve the problem by moving this check to lock_tables(), so it can be performed after exact lock types for tables used by multi-UPDATE are determined. mysql-test/r/trigger.result: Results for the added test case is added. mysql-test/t/trigger.test: A new test case is added, verifying correct table multi-update conflict resolution, both read-only and write. sql/sql_base.cc: The check for conflicting use of tables in SP/triggers is moved to lock_tables(), to be performed after the exact lock types have been determined. Also, an assert is added to open_ltable() to ensure this func is not used in a prelocked context.
-
Alexey Kopytov authored
UNION could convert fixed-point FLOAT(M,D)/DOUBLE(M,D) columns to FLOAT/DOUBLE when aggregating data types from the SELECT substatements. While there is nothing particularly wrong with this behavior, especially when M is greater than the hardware precision limits, it could be confusing in cases when all SELECT statements in a union have the same FLOAT(M,D)/DOUBLE(M,D) columns with equal precision specifications listed in the same position. Since the manual is quite vague on what data type should be returned in such cases, the bug was fixed by implementing the most 'expected' behavior: do not convert FLOAT(M,D)/DOUBLE(M,D) to anything else if all SELECT statements in a UNION have the same precision for that column. mysql-test/r/union.result: Added a test case for bug #43432. mysql-test/t/union.test: Added a test case for bug #43432. sql/field.cc: Replaced FLT_DIG+6 and DBL_DIG+7 with a symbolic constant. sql/item.cc: Do not convert FLOAT(M,D)/DOUBLE(M,D) to anything else if all SELECT statements in a UNION have the same precision for that column. sql/mysql_priv.h: Added a symbolic constant for FLT_DIG+6 and DBL_DIG+7.
-
Ramil Kalimullin authored
Problem: commit doesn't delete savepoints if there are no changes in the transaction. Fix: delete them in such cases. mysql-test/r/innodb_mysql.result: Fix for bug #26288: savepoint not deleted, comit on empty transaction - test result. mysql-test/t/innodb_mysql.test: Fix for bug #26288: savepoint not deleted, comit on empty transaction - test case. sql/handler.cc: Fix for bug #26288: savepoint not deleted, comit on empty transaction - call transaction.cleanup() even if nht is 0 to delete possible savepoints.
-
Leonard Zhou authored
-
- 26 Mar, 2009 3 commits
-
-
Davi Arnaut authored
The problem is that the read and write methods of the shared memory transport (protocol) didn't react to asynchronous close events, which could lead to a lock up as the client would wait (until time out) for a server response that will never come. The solution is to also wait for close events while waiting for I/O from or to the server. mysql-test/r/shm.result: Add test case result for Bug#33899 mysql-test/t/shm.test: Add test case for Bug#33899 vio/viosocket.c: Also wait for close events.
-
Matthias Leich authored
including modifications according to code review + backport of the fix for Bug 41932 funcs_1: is_collation_character_set_applicability path too long for tar which was missing in 5.0 (just a renaming of two files)
-
Leonard Zhou authored
When add an aliase name after NAME_CONST, the aliase name will be overwrite. NAME_CONST will re-set the field's name only if there isn't an aliase in the function fix-fields(). If there is an aliase, NAME_CONST doesn't re-set the field's name and keeps the old name. mysql-test/r/func_misc.result: Test result. mysql-test/r/rpl_name_const.result: Test case. mysql-test/t/func_misc.test: Add NAME_CONST test. mysql-test/t/rpl_name_const.test: Test result. sql/item.cc: Re-set field's name if the name is autogenerated, that mean without aliase.
-
- 25 Mar, 2009 9 commits
-
-
Ramil Kalimullin authored
-
Ramil Kalimullin authored
due to name_const substitution Problem: "In general, statements executed within a stored procedure are written to the binary log using the same rules that would apply were the statements to be executed in standalone fashion. Some special care is taken when logging procedure statements because statement execution within procedures is not quite the same as in non-procedure context". For example, each reference to a local variable in SP's statements is replaced by NAME_CONST(var_name, var_value). Queries like "CREATE TABLE ... SELECT FUNC(local_var ..." are logged as "CREATE TABLE ... SELECT FUNC(NAME_CONST("local_var", var_value) ..." that leads to differrent field names and might result in "Incorrect column name" if var_value is long enough. Fix: in 5.x we'll issue a warning in such a case. In 6.0 we should get rid of NAME_CONST(). Note: this issue and change should be described in the documentation ("Binary Logging of Stored Programs"). mysql-test/r/binlog.result: Fix for bug#35383: binlog playback and replication breaks due to name_const substitution - test result. mysql-test/t/binlog.test: Fix for bug#35383: binlog playback and replication breaks due to name_const substitution - test case. sql/sp_head.cc: Fix for bug#35383: binlog playback and replication breaks due to name_const substitution - set thd->query_name_consts if there's NAME_CONST() substitution(s). sql/sql_parse.cc: Fix for bug#35383: binlog playback and replication breaks due to name_const substitution - issue a warning if there's NAME_CONST() substitution and binary logging is on for "CREATE TABLE ... SELECT ...".
-
Tatiana A. Nurnberg authored
Fine-tuning. Broke out comparison into method by suggestion of Davi. Clarified comments. Reverting test-case which I find too brittle; proper test case in 5.1+.
-
Georgi Kodinov authored
(Pushing for Azundris) We allow security-contexts with NULL users (for system-threads and for unauthenticated users). If a non-SUPER-user tried to KILL such a thread, we tried to compare the user-fields to see whether they owned that thread. Comparing against NULL was not a good idea. If KILLer does not have SUPER-privilege, we specifically check whether both KILLer and KILLee have a non-NULL user before testing for string- equality. If either is NULL, we reject the KILL. mysql-test/r/rpl_temporary.result: Try to have a non-SUPER user KILL a system thread. mysql-test/t/rpl_temporary.test: Try to have a non-SUPER user KILL a system thread. sql/sql_parse.cc: Make sure security contexts of both KILLer *and* KILLee are non-NULL before testing for string-equality!
-
Alexey Kopytov authored
-
Chad MILLER authored
-
Satya B authored
-
Satya B authored
After the table is compressed by the myisampack utility, opening the table by the server produces valgrind warnings. This happens because when we try to read a record into the buffer we alway assume that the remaining buffer to read is always equal to word size(4 or 8 or 2 bytes) we read. Sometimes we have remaining buffer size less than word size and trying to read the entire word size will end up in valgrind errors. Fixed by reading byte by byte when we detect the remaining buffer size is less than the word size. myisam/mi_packrec.c: Fixed fill_buffer() to read byte by byte when the remaining buffer size is less than word size. mysql-test/r/myisampack.result: Result file for BUG#41541 mysql-test/t/myisampack.test: Testcase for BUG#41541
-
Leonard Zhou authored
-
- 24 Mar, 2009 5 commits
-
-
Alexey Kopytov authored
-
Alexey Kopytov authored
expired timeout on debx86-b in PB Moved the resource-intensive test case for bug #41486 into a separate test file to reduce execution time for mysql.test. mysql-test/include/wait_until_disconnected.inc: Used in mysql-bug41486.test. mysql-test/r/mysql-bug41486.result: Moved the resource-intensive test case for bug #41486 into a separate test file to reduce execution time for mysql.test. mysql-test/r/mysql.result: Moved the resource-intensive test case for bug #41486 into a separate test file to reduce execution time for mysql.test. mysql-test/t/mysql-bug41486.test: Moved the resource-intensive test case for bug #41486 into a separate test file to reduce execution time for mysql.test. mysql-test/t/mysql.test: Moved the resource-intensive test case for bug #41486 into a separate test file to reduce execution time for mysql.test.
-
Alexey Kopytov authored
produce incorrect results for ROUND() Added a workaround and a configure check to test whether isinf() is affected by the GCC bug #39228. Since no code in MySQL server is currently affected by that bug, the patch is actually a safeguard for possible future code modifications. No test cases or changelog entries are needed. configure.in: Added a configure check to test whether isinf() is safe to use in C code. include/my_global.h: Added a workaround for GCC bug #39228.
-
Leonard Zhou authored
-
Leonard Zhou authored
When do 'insert delayed' operation, the time_zone info doesn't be keeped in the row info. So when we do insert sometime later, time_zone didn't write into binlog. This will cause wrong result for timestamp column in slave. Our solution is that adding time_zone info with the delayed-row and restoring time_zone from row-info when execute that row in the furture by another thread. So we can write correct time_zone info into binlog and got correct result in slave. mysql-test/r/rpl_timezone.result: Test result mysql-test/t/rpl_timezone.test: Add test for bug#41719 sql/sql_insert.cc: Add time_zone info in the delayed-row and restore time_zone when execute the row in the furture by another thread.
-
- 23 Mar, 2009 5 commits
-
-
Matthias Leich authored
-
Matthias Leich authored
Details for Bug#43015 main.lock_multi: Weak code (sleeps etc.) ------------------------------------------------------------- - The fix for bug 42003 already removed a lot of the weaknesses mentioned. - Tests showed that there are unfortunately no improvements of this tests in MySQL 5.1 which could be ported back to 5.0. - Remove a superfluous "--sleep 1" around line 195 Details for Bug#43065 main.lock_multi: This test is too big if the disk is slow ------------------------------------------------------------------------------- - move the subtests for the bugs 38499 and 36691 into separate scripts - runtime under excessive parallel I/O load after applying the fix lock_multi [ pass ] 22887 lock_multi_bug38499 [ pass ] 536926 lock_multi_bug38691 [ pass ] 258498
-
Sergey Glukhov authored
-
Tatiana A. Nurnberg authored
-
Tatiana A. Nurnberg authored
When asking what database is selected, client expected to *always* get an answer from the server. We now handle failure more gracefully. See comments in ticket for a discussion of what happens, and how things interlock. client/mysql.cc: Handle empty result-sets gracefully, as opposed to just result sets with n>0 items that may themselves be empty.
-
- 20 Mar, 2009 1 commit
-
-
Narayanan V authored
-
- 19 Mar, 2009 7 commits
-
-
Davi Arnaut authored
Don't compare string literals as it results in unspecified behavior. mysys/default.c: Test for a empty string.
-
Ignacio Galarza authored
-
Bernt M. Johnsen authored
-
Ignacio Galarza authored
-
Staale Smedseng authored
functions Unknown timezone specifications are properly rejected by the server, but are copied into tz_storage before rejection, and hence is retained until end of server life. With sufficiently large bogus timezone specs, it is easy to exhaust system memory. Allocation of memory for a copy of the timezone name is delayed until after verification of validity, at the cost of a memcpy of the timezone info. This only happens once, future lookups will hit the cached structure.
-
Alexey Kopytov authored
-
Alexey Kopytov authored
for bug #41486. Session max_allowed_packet is read-only as of MySQL 5.1.31. In addition, the global variable now has no effect on the current session.
-