- 08 Jun, 2010 7 commits
-
-
Davi Arnaut authored
config/ac-macros/ssl.m4: Enable yaSSL thread safety if linking with the server or a thread safe client library. Avoids building a thread safe yaSSL when only building a non-thread safe client library.
-
Davi Arnaut authored
include/my_sys.h: Remove stray semicolon.
-
Davi Arnaut authored
The problem was that the bundled yaSSL library was being built without thread safety support regardless of the thread safeness of the compoments linked with it. The solution is to enable yaSSL thread safety support if any component (server or client) is to be built with thread support. Also, generate new certificates for yaSSL's test suite. config/ac-macros/yassl.m4: Enable yaSSL thread safety if linking with the server or a thread safe client library. Avoids building a thread safe yaSSL when only building a non-thread safe client library. extra/yassl/CMakeLists.txt: Always enable for Windows builds. extra/yassl/certs/ca-cert.pem: New certificate, previous one expired. extra/yassl/certs/client-cert.der: New certificate, previous one expired. extra/yassl/certs/client-cert.pem: New certificate, previous one expired. extra/yassl/certs/dsa-cert.pem: New certificate, previous one expired. extra/yassl/certs/server-cert.pem: New certificate, previous one expired. extra/yassl/include/lock.hpp: Rename MULTI_THREAD to YASSL_THREAD_SAFE. extra/yassl/src/Makefile.am: Use CXXFLAGS to set thread related definitions as the lock header (lock.hpp) has no local dependencies. extra/yassl/src/lock.cpp: Rename MULTI_THREAD to YASSL_THREAD_SAFE. extra/yassl/taocrypt/CMakeLists.txt: Always enable for Windows builds. extra/yassl/taocrypt/benchmark/Makefile.am: Pass thread related CXXFLAGS. extra/yassl/taocrypt/src/Makefile.am: Pass thread related CXXFLAGS. extra/yassl/taocrypt/test/Makefile.am: Pass thread related CXXFLAGS. extra/yassl/taocrypt/test/memory.cpp: Rename MULTI_THREAD to YASSL_THREAD_SAFE. extra/yassl/testsuite/Makefile.am: Pass thread related CXXFLAGS.
-
Kristofer Pettersson authored
-
Kristofer Pettersson authored
Logging slow stored procedures caused the slow log to write very large lock times. The lock times was a result of a negative number being cast to an unsigned integer. The reason the lock time appeard negative was because one of the measurements points was reset after execution causing it to change order with the start time of the statement. This bug is related to bug 47905 which in turn was introduced because of a joint fix for 12480,12481,12482 and 11587. The fix is to only reset the start_time before any statement execution in a SP while not resetting start_utime or utime_after_lock which are used for measuring the performance of the SP. Start_time is used to set the timestamp on the replication event which controlls how the slave interprets time functions like NOW().
-
Sergey Glukhov authored
-
Sergey Glukhov authored
The problem is in the Item_func_isnull::update_used_tables() function, bracket is at the wrong place. Because of that isnull item erroneously is treated as const item. The fix is to set brackets in the right place. mysql-test/r/func_isnull.result: test case mysql-test/t/func_isnull.test: test case sql/item_cmpfunc.h: set brackets in the right place.
-
- 07 Jun, 2010 2 commits
-
-
Georgi Kodinov authored
-
Georgi Kodinov authored
when an out-of-supported-range date is detected.
-
- 04 Jun, 2010 5 commits
-
-
Ramil Kalimullin authored
-
Ramil Kalimullin authored
NET::skip_big_packet isn't defined for the embedded server, hide it in such a case. sql/sql_connect.cc: Fix for bug #53912: Fails to build from source - hide net.skip_big_packet for the embedded server, as it isn't defined there.
-
Georgi Kodinov authored
-
Georgi Kodinov authored
Some of the server implementations don't support dates later than 2038 due to the internal time type being 32 bit. Added checks so that the server will refuse dates that cannot be handled by either throwing an error when setting date at runtime or by refusing to start or shutting down the server if the system date cannot be stored in my_time_t.
-
Horst.Hunger authored
Patch for bug#52913: Inserted check if mysqlhotcopy script is existing as requested by review. DIsabled the test until bug#54129 will befixed.
-
- 03 Jun, 2010 4 commits
-
-
Luis Soares authored
Post-push fix.
-
Luis Soares authored
Post-push fix. There was a valgrind issue on the loop that checks whether there are NULL fields in the UNIQUE KEY or not. In detail, for the last iteration the server may read out of the key_part array boundaries, making valgrind to output warnings. We fix this by correcting the loop, ie, moving the part that reads from the key_part to be inside the loop statement block. This way the assignment is protected by the loop condition.
-
Davi Arnaut authored
-
Horst.Hunger authored
-
- 02 Jun, 2010 5 commits
-
-
Luis Soares authored
-
Luis Soares authored
When using Unique Keys with nullable parts in RBR, the slave can choose the wrong row to update. This happens because a table with an unique key containing nullable parts cannot strictly guarantee uniqueness. As stated in the manual, for all engines, a UNIQUE index allows multiple NULL values for columns that can contain NULL. We fix this at the slave by extending the checks before assuming that the row found through an unique index is is the correct one. This means that when a record (R) is fetched from the storage engine and a key that is not primary (K) is used, the server does the following: - If K is unique and has no nullable parts, it returns R; - Otherwise, if any field in the before image that is part of K is null do an index scan; - If there is no NULL field in the BI part of K, then return R. A side change: renamed the existing test case file and added a test case covering the changes in this patch.
-
Luis Soares authored
-
Luis Soares authored
MTR will ignore fully qualified test name entries in disabled.def lists. Therefore, it would still run the test case, even if it is listed. This patch fix this by extending the check when marking the test case as disabled to take into consideration not only the cases that contain the simple test name but also those that contain fully qualified test names.
-
Alexey Kopytov authored
-
- 01 Jun, 2010 7 commits
-
-
Georgi Kodinov authored
-
Georgi Kodinov authored
-
Georgi Kodinov authored
-
Georgi Kodinov authored
-
Georgi Kodinov authored
-
Sergey Glukhov authored
-
Mattias Jonsson authored
result file differs on embedded
-
- 31 May, 2010 2 commits
-
-
Sergey Glukhov authored
Field_time::get_date method does not initialize MYSQL_TIME::time_type field. The fix is to init this field. mysql-test/r/type_time.result: test case mysql-test/t/type_time.test: test case sql/field.cc: --use Field_time::get_time in Field_time::get_date --removed duplicated code in Field_time::get_date method
-
Vasil Dimov authored
-
- 29 May, 2010 1 commit
-
-
Alexey Kopytov authored
and .tar.gz, windows vs linux.. On Intel x86 machines index selection by the MySQL query optimizer could sometimes depend on the compiler version and optimization flags used to build the server binary. The problem was a result of a known issue with floating point calculations on x86: since internal FPU precision (80 bit) differs from precision used by programs (32-bit float or 64-bit double), the result of calculating a complex expression may depend on how FPU registers are allocated by the compiler and whether intermediate values are spilled from FPU to memory. In this particular case compiler versions and optimization flags had an effect on cost calculation when choosing the best index in best_access_path(). A possible solution to this problem which has already been implemented in mysql-trunk is to limit FPU internal precision to 64 bits. So the fix is a backport of the relevant code to 5.1 from mysql-trunk. configure.in: Configure check for fpu_control.h mysql-test/r/explain.result: Test case for bug #48537. mysql-test/t/explain.test: Test case for bug #48537. sql/mysqld.cc: Backport of the code to switch FPU on x86 to 64-bit precision.
-
- 28 May, 2010 3 commits
-
-
Jimmy Yang authored
err_index could be not a member of the share structure or prebuilt structure passed from MySQL. For now, we resort to the traditional way of scanning index->table for the index number.
-
Mattias Jonsson authored
-
unknown authored
Add code to waiting for a set of errors. Add code to waiting for an error instead of waiting for io thread to stop, as after 'START SLAVE', the status of io thread is still not running. But it doesn't mean slave io thread encounters an error.
-
- 27 May, 2010 4 commits
-
-
Dmitry Lenev authored
without FOR UPDATE is causing a lock". SELECT statements with subqueries referencing InnoDB tables were acquiring shared locks on rows in these tables when they were executed in REPEATABLE-READ mode and with statement or mixed mode binary logging turned on. This was a regression which were introduced when fixing bug 39843. The problem was that for tables belonging to subqueries parser set TL_READ_DEFAULT as a lock type. In cases when statement/mixed binary logging at open_tables() time this type of lock was converted to TL_READ_NO_INSERT lock at open_tables() time and caused InnoDB engine to acquire shared locks on reads from these tables. Although in some cases such behavior was correct (e.g. for subqueries in DELETE) in case of SELECT it has caused unnecessary locking. This patch implements minimal version of the fix for the specific problem described in the bug-report which supposed to be not too risky for pushing into 5.1 tree. The 5.5 tree already contains a more appropriate solution which also addresses other related issues like bug 53921 "Wrong locks for SELECTs used stored functions may lead to broken SBR". This patch tries to solve the problem by ensuring that TL_READ_DEFAULT lock which is set in the parser for tables participating in subqueries at open_tables() time is interpreted as TL_READ_NO_INSERT or TL_READ. TL_READ is used only if we know that this is a SELECT and that this particular table is not used by a stored function. Test coverage is added for both InnoDB and MyISAM. This patch introduces an "incompatible" change in locking scheme for subqueries used in SELECT ... FOR UPDATE and SELECT .. IN SHARE MODE. In 4.1 (as well as in 5.0 and 5.1 before fix for bug 39843) the server would use a snapshot InnoDB read for subqueries in SELECT FOR UPDATE and SELECT .. IN SHARE MODE statements, regardless of whether the binary log is on or off. If the user required a different type of read (i.e. locking read), he/she could request so explicitly by providing FOR UPDATE/IN SHARE MODE clause for each individual subquery. The patch for bug 39843 broke this behaviour (which was not documented or tested), and started to use locking reads for all subqueries in SELECT ... FOR UPDATE/IN SHARE MODE. This patch restores 4.1 behaviour. This patch should be mostly null-merged into 5.5 tree. mysql-test/include/check_concurrent_insert.inc: Added auxiliary script which allows to check if statement reading table allows concurrent inserts in it. mysql-test/include/check_no_concurrent_insert.inc: Added auxiliary script which allows to check that statement reading table doesn't allow concurrent inserts in it. mysql-test/include/check_no_row_lock.inc: Added auxiliary script which allows to check if statement reading table doesn't take locks on its rows. mysql-test/include/check_shared_row_lock.inc: Added auxiliary script which allows to check if statement reading table takes shared locks on some of its rows. mysql-test/r/bug39022.result: After bug #46947 'Embedded SELECT without FOR UPDATE is causing a lock' was fixed test case for bug 39022 has to be adjusted in order to trigger execution path on which original problem was encountered. mysql-test/r/innodb_mysql_lock2.result: Added coverage for handling of locking in various cases when we read data from InnoDB tables (includes test case for bug #46947 'Embedded SELECT without FOR UPDATE is causing a lock'). mysql-test/r/lock_sync.result: Added coverage for handling of locking in various cases when we read data from MyISAM tables. mysql-test/t/bug39022.test: After bug #46947 'Embedded SELECT without FOR UPDATE is causing a lock' was fixed test case for bug 39022 has to be adjusted in order to trigger execution path on which original problem was encountered. mysql-test/t/innodb_mysql_lock2.test: Added coverage for handling of locking in various cases when we read data from InnoDB tables (includes test case for bug #46947 'Embedded SELECT without FOR UPDATE is causing a lock'). mysql-test/t/lock_sync.test: Added coverage for handling of locking in various cases when we read data from MyISAM tables. sql/mysql_priv.h: Function read_lock_type_for_table() now takes pointers to LEX and TABLE_LIST elements as its arguments since to correctly determine lock type it needs to know what statement is being performed and whether table element for which lock type to be determined belongs to prelocking list. sql/sql_base.cc: Changed read_lock_type_for_table() to return a weak TL_READ type of lock in cases when we are executing SELECT (and so won't update tables directly) and table doesn't belong to statement's prelocking list and thus can't be used by a stored function. It is OK to do so since in this case table won't be used by statement or function call which will be written to the binary log, so serializability requirements for it can be relaxed. One of results from this change is that SELECTs on InnoDB tables no longer takes shared row locks for tables which are used in subqueries (i.e. bug #46947 is fixed). Another result is that for similar SELECTs on MyISAM tables concurrent inserts are allowed. In order to implement this change signature of read_lock_type_for_table() function was changed to take pointers to LEX and TABLE_LIST objects. sql/sql_update.cc: Function read_lock_type_for_table() now takes pointers to LEX and TABLE_LIST elements as its arguments since to correctly determine lock type it needs to know what statement is being performed and whether table element for which lock type to be determined belongs to prelocking list.
-
Inaam Rana authored
list a thread doing a wait_ex as an s-lock waiter.
-
Sergey Glukhov authored
There are two problems: 1. In simplify_joins function we calculate table dependencies. If STRAIGHT_JOIN hint is used for whole SELECT we do not count it and as result some dependendecies might be lost. It leads to incorrect table order which is returned by join_tab_cmp_straight() function. 2. make_join_statistics() calculate the transitive closure for relations a particular JOIN_TAB is 'dependent on'. We aggregate the dependent table_map of a JOIN_TAB by adding dependencies from other tables which we depend on. However, this may also cause new dependencies to be available after we have completed processing a certain JOIN_TAB. Both these problems affect condition pushdown and as result condition might be pushed into wrong table which leads to crash or even omitted which leads to wrong result. The fix: 1. Use modified 'transitive closure' algorithm provided by Ole John Aske 2. Update table dependences in simplify_joins according to global STRAIGHT_JOIN hint. Note: the patch also fixes bugs 46091 & 51492 mysql-test/r/join_outer.result: test case mysql-test/t/join_outer.test: test case sql/sql_select.cc: 1. Use modified 'transitive closure' algorithm provided by Ole John Aske 2. Update table dependences in simplify_joins according to global STRAIGHT_JOIN hint.
-
Alexey Kopytov authored
-