- 14 Apr, 2010 1 commit
-
-
Jon Olav Hauglid authored
during rqg_mdl_deadlock test The problem was that if two connection threads simultaneously tries to execute "SET GLOBAL EVENT_SCHEDULER = OFF", one of them could hang waiting for the scheduler to stop. The first connection thread would kill the event scheduler thread and then start waiting for it to exit. The second connection thread would then find the event scheduler thread in the process of exiting and also wait for it to exit. However, since the event scheduler thread used signal to wake only one waiting thread, the other connection thread would be left waiting. This bug was a regression introduced by the fix for Bug#51160. Before #51160 it was not possible for two connection threads to try to stop the event scheduler thread simultaneously. This patch fixes the problem my making sure the event scheduler thread uses broadcast to notify all waiters that it is exiting. No test case added as this would require adding debug sync points to parts of the code where sync points are currently not used. The patch has been tested with the non-deterministic test case from the bug description as well as using the RQG.
-
- 17 Mar, 2010 2 commits
-
-
Davi Arnaut authored
-
Davi Arnaut authored
-
- 16 Mar, 2010 1 commit
-
-
Alexander Nozdrin authored
-
- 15 Mar, 2010 11 commits
-
-
Mats Kindahl authored
-
Mats Kindahl authored
-
Konstantin Osipov authored
DDL no longer aborts mysql_lock_tables(), and hence we no longer need to support need_reopen flag of this call. Remove the flag, and all the code in the server that was responsible for handling the case when it was set. This allowed to simplify: open_and_lock_tables_derived(), the delayed thread, multi-update. Rename MYSQL_LOCK_IGNORE_FLUSH to MYSQL_OPEN_IGNORE_FLUSH, since we now only support this flag in open_table(). Rename MYSQL_LOCK_PERF_SCHEMA to MYSQL_LOCK_LOG_TABLE, to avoid confusion. Move the wait for the global read lock for cases when we do updates in SELECT f1() or DO (UPDATE) to open_table() from mysql_lock_tables(). When waiting for the read lock, we could raise need_reopen flag, which is no longer present in mysql_lock_tables(). Since the block responsible for waiting for GRL was moved, MYSQL_LOCK_IGNORE_GLOBAL_READ_LOCK was renamed to MYSQL_OPEN_IGNORE_GLOBAL_READ_LOCK.
-
Vladislav Vaintroub authored
-
Alexander Nozdrin authored
-
Alexander Nozdrin authored
Use new command line options instead of deprecated and removed ones.
-
Alexander Nozdrin authored
-
Magnus Blåudd authored
-
Magnus Blåudd authored
-
Jon Olav Hauglid authored
This deadlock could occour betweeen one connection executing SET GLOBAL EVENT_SCHEDULER= ON and another executing SET GLOBAL EVENT_SCHEDULER= OFF. The bug was introduced by WL#4738. The first connection would hold LOCK_event_metadata (protecting the global variable) while trying to lock LOCK_global_system_variables starting the event scheduler thread (in THD:init()). The second connection would hold LOCK_global_system_variables while trying to get LOCK_event_scheduler after stopping the event scheduler inside event_scheduler_update(). This patch fixes the problem by not using LOCK_event_metadata to protect the event_scheduler variable. It is still protected using LOCK_global_system_variables. This fixes the deadlock as it removes one of the two mutexes used to produce it. However, this patch opens up the possibility that the event_scheduler variable and the real event_scheduler state can become out of sync (e.g. variable = OFF, but scheduler running). But this can only happen under very unlikely conditions - two concurrent SET GLOBAL statments, with one thread interrupted at the exact wrong moment. This is preferable to having the possibility of a deadlock. This patch also fixes a bug where it was possible to exit create_event() without releasing LOCK_event_metadata if running out of memory during its exection. No test case added since a repeatable test case would have required excessive use of new sync points. Instead we rely on the fact that this bug was easily reproduceable using RGQ tests.
-
Alexander Nozdrin authored
-
- 14 Mar, 2010 1 commit
-
-
Mats Kindahl authored
When building the script directory using a CMake-based build, both the variables in config.h.cmake (including PLUGINDIR) and the variables in CMakeList.txt (which includes pkgplugindir). However, for autotools-based builds, only pkgplugindir is substituted, which means that the plugin-path is not substituted. This patch solves the problem by using pkgplugindir, which works on both CMake-based and autotools-based builds, instead of PLUGINDIR.
-
- 13 Mar, 2010 1 commit
-
-
Konstantin Osipov authored
Remove unnecessary need_reopen loops.
-
- 12 Mar, 2010 8 commits
-
-
joerg.bruehe@sun.com authored
-
Alexander Nozdrin authored
-
Alexander Nozdrin authored
-
Alexander Nozdrin authored
-
Alexander Nozdrin authored
-
Alexander Nozdrin authored
-
Luis Soares authored
There are two issues fixed here: 1. We needed to update the result file, for some of mysqlbinlog_* tests, because now the some padding chars are not output anymore. 2. We needed to change the Field_string::pack so that for BINARY types the padding chars are not packed (lengthsp will return full length for these types).
-
Joerg Bruehe authored
-
- 11 Mar, 2010 8 commits
-
-
Joerg Bruehe authored
-
Vladislav Vaintroub authored
Unquoted ${CMAKE_CPACK_COMMAND} is used in this script. This variable resolves to cpack's real path with spaces, e.g /Applications/CMake 2.6.4-app/Contents/bin/cpack. Script fails due to lack of quotes. Fix is to use quotes around ${CMAKE_CPACK_COMMAND}.
-
Konstantin Osipov authored
The problem is introduced by WL#4435 "Support OUT-parameters in prepared statements". When a statement that has out parameters was reprepared, the reprepare request error was ignored, and an attempt to send out parameters to the client was made. Since the out parameter list was not initialized in case of an error, this attempt led to a crash. Don't try to send out parameters to the client if an error occurred in statement execution.
-
Luis Soares authored
-
Alexander Barkov authored
- Fixing crash on attempt to create a fulltext index with an utf8mb4 column - fixing wrong border width for supplementary characters in mysql client: mysql --default-character-set=utf8mb4 -e "select concat(_utf32 0x20000,'a')"
-
He Zhenxing authored
-
He Zhenxing authored
-
He Zhenxing authored
-
- 10 Mar, 2010 7 commits
-
-
Luis Soares authored
Split rpl_row_charset into: - rpl_row_utf16. - rpl_row_utf32. This way these tests can run independently if server supports either one of the charsets but not both. Cleaned up rpl_row_utf32 which had a spurious instruction: -- let $reset_slave_type_conversions= 0
-
Davi Arnaut authored
-
Luis Soares authored
In BUG#51787 we were using the wrong charset to print out the data. We were using the field charset for the string that would hold the information. This caused the assertion, because the string length was not aligned with UTF32 bytes requirements for storage. We fix this by using &my_charset_latin1 in the string object instead of the field->charset(). As a side-effect, we needed to extend the show_sql_type interface so that it took the field charset is now passed as a parameter, so that one is able to calculate the correct field size. In BUG#51716 we had issues with Field_string::pack and Field_string::unpack. When packing, the length was incorrectly calculated. When unpacking, the padding the string would be padded with the wrong bytes (a few bytes less than it should). We fix this by resorting to charset abstractions (functions) that calculate the correct length when packing and pad correctly the string when unpacking.
-
Joerg Bruehe authored
-
Alexander Nozdrin authored
-
Konstantin Osipov authored
LOCK kills the server. Prohibit FLUSH TABLES WITH READ LOCK application to views or temporary tables. Fix a subtle bug in the implementation when we actually did not remove table share objects from the table cache after acquiring exclusive locks.
-
Davi Arnaut authored
The problem was that in read only mode (read_only enabled), the server would mistakenly deny data modification attempts for temporary tables which belong to a transactional storage engine (eg. InnoDB). The solution is to allow transactional temporary tables to be modified under read only mode. As a whole, the read only mode does not apply to any kind of temporary table.
-