- 18 Jun, 2009 7 commits
-
-
Davi Arnaut authored
The problem was that a pthread.h header used by gcc did not declare the pthread_setscheprio, yet the function is implemented by the function is implemented, causing a autoconf check to pass and compilation with C++ to fail. The solution is to add a autoconf check to ensure that the function is properly declared. configure.in: Check that the pthread_setschedprio is declared.
-
Alfranio Correia authored
-
Alfranio Correia authored
-
Alfranio Correia authored
-
Alfranio Correia authored
-
Alfranio Correia authored
Large transactions and statements may corrupt the binary log if the size of the cache, which is set by the max_binlog_cache_size, is not enough to store the the changes. In a nutshell, to fix the bug, we save the position of the next character in the cache before starting processing a statement. If there is a problem, we simply restore the position thus removing any effect of the statement from the cache. Unfortunately, to avoid corrupting the binary log, we may end up loosing changes on non-transactional tables if they do not fit in the cache. In such cases, we store an Incident_log_event in order to stop the slave and alert users that some changes were not logged. Precisely, for every non-transactional changes that do not fit into the cache, we do the following: a) the statement is *not* logged b) an incident event is logged after committing/rolling back the transaction, if any. Note that if a failure happens before writing the incident event to the binary log, the slave will not stop and the master will not have reported any error. c) its respective statement gives an error For transactional changes that do not fit into the cache, we do the following: a) the statement is *not* logged b) its respective statement gives an error To work properly, this patch requires two additional things. Firstly, callers to MYSQL_BIN_LOG::write and THD::binlog_query must handle any error returned and take the appropriate actions such as undoing the effects of a statement. We already changed some calls in the sql_insert.cc, sql_update.cc and sql_insert.cc modules but the remaining calls spread all over the code should be handled in BUG#37148. Secondly, statements must be either classified as DDL or DML because DDLs that do not get into the cache must generate an incident event since they cannot be rolled back.
-
Martin Hansson authored
-
- 17 Jun, 2009 17 commits
-
-
Alexey Kopytov authored
-
Alexey Kopytov authored
-
Alexey Kopytov authored
-
Alexey Kopytov authored
-
Alexey Kopytov authored
-
Staale Smedseng authored
-
Martin Hansson authored
-
Staale Smedseng authored
-
Kristofer Pettersson authored
-
Martin Hansson authored
Item_func_spatial_collection::val_str When the concatenation function for geometry data collections reads the binary data it was not rigorous in checking that there is data available, leading to invalid reads and crashes. Fixed by making checking stricter. mysql-test/r/gis.result: Bug#44684: Test result mysql-test/t/gis.test: Bug#44684: Test case sql/item_geofunc.cc: Bug#44684: fix(es) - Check that there are 4 bytes available for type code. - Check that there is at least one point available for linestring. - Check that there are at least 2 points in a polygon and data for all the points.
-
Staale Smedseng authored
-
Kristofer Pettersson authored
This patch corrects a misstake in the test case for bug patch 43658. There was a race in the test case when the thread id was retrieved from the processlist. The result was that the same thread id was signalled twice and one thread id wasn't signalled at all. The affected platforms appears to be limited to linux. mysql-test/r/query_cache_debug.result: There was a race in the test case when the thread id was retrieved from the processlist. The result was that the same thread id was signalled twice and one thread id wasn't signalled at all. mysql-test/t/query_cache_debug.test: There was a race in the test case when the thread id was retrieved from the processlist. The result was that the same thread id was signalled twice and one thread id wasn't signalled at all.
-
Staale Smedseng authored
with gcc 4.3.2 Compiling MySQL with gcc 4.3.2 and later produces a number of warnings, many of which are new with the recent compiler versions. This bug will be resolved in more than one patch to limit the size of changesets. This is the second patch, fixing more of the warnings.
-
Alexey Kopytov authored
-
Alexey Kopytov authored
-
Alexey Kopytov authored
-
Alexey Kopytov authored
-
- 16 Jun, 2009 11 commits
-
-
Alfranio Correia authored
This is a backport of BUG#43076.
-
Martin Hansson authored
The assertion in String::copy was added in order to avoid valgrind errors when the destination was the same as the source. Eased restriction to allow for the case when str == NULL. mysql-test/r/func_set.result: Bug#45168: Test result mysql-test/t/func_set.test: Bug#45168: Test case sql/item_strfunc.cc: Bug#45168: Code cleanup and grammar correction in comment sql/sql_string.cc: Bug#45168: Fix
-
Georgi Kodinov authored
to a test file that guarantees the presence of partition code
-
Kristofer Pettersson authored
-
Kristofer Pettersson authored
-
Martin Hansson authored
-
Kristofer Pettersson authored
-
Georgi Kodinov authored
-
Kristofer Pettersson authored
Early patch submitted for discussion. It is possible for more than one thread to enter the condition in query_cache_insert(), but the condition predicate is to signal one thread each time the cache status changes between the following states: {NO_FLUSH_IN_PROGRESS,FLUSH_IN_PROGRESS, TABLE_FLUSH_IN_PROGRESS} Consider three threads THD1, THD2, THD3 THD2: select ... => Got a writer in ::store_query THD3: select ... => Got a writer in ::store_query THD1: flush tables => qc status= FLUSH_IN_PROGRESS; new writers are blocked. THD2: select ... => Still got a writer and enters cond in query_cache_insert THD3: select ... => Still got a writer and enters cond in query_cache_insert THD1: flush tables => finished and signal status change. THD2: select ... => Wakes up and completes the insert. THD3: select ... => Happily waiting for better times. Why hurry? This patch is a refactoring of this lock system. It introduces four new methods: Query_cache::try_lock() Query_cache::lock() Query_cache::lock_and_suspend() Query_cache::unlock() This change also deprecates wait_while_table_flush_is_in_progress(). All threads are queued and put on a conditional wait. On each unlock the queue is signalled. This resolve the issues with left over threads. To assure that no threads are spending unnecessary time waiting a signal broadcast is issued every time a lock is taken before a full cache flush. mysql-test/r/query_cache_debug.result: * Added test case for bug43758 mysql-test/t/query_cache_debug.test: * Added test case for bug43758 sql/sql_cache.cc: * Replaced calls to wait_while_table_flush_is_in_progress() with calls to try_lock(), lock_and_suspend() and unlock(). * Renamed enumeration Cache_status to Cache_lock_status. * Renamed enumeration items to UNLOCKED, LOCKED_NO_WAIT and LOCKED. If the LOCKED_NO_WAIT lock type is used to lock the query cache, other threads using try_lock() will fail to acquire the lock. This is useful if the query cache is temporary disabled due to a full table flush. sql/sql_cache.h: * Replaced calls to wait_while_table_flush_is_in_progress() with calls to try_lock(), lock_and_suspend() and unlock(). * Renamed enumeration Cache_status to Cache_lock_status. * Renamed enumeration items to UNLOCKED, LOCKED_NO_WAIT and LOCKED. If the LOCKED_NO_WAIT lock type is used to lock the query cache, other threads using try_lock() will fail to acquire the lock. This is useful if the query cache is temporary disabled due to a full table flush.
-
Martin Hansson authored
-
Georgi Kodinov authored
-
- 15 Jun, 2009 5 commits
-
-
Davi Arnaut authored
times (ie: 2:16:20). mysql-test/r/log_tables_debug.result: Update test case result. mysql-test/t/log_tables_debug.test: Skip spaces and handle case when a leading zero is not printed.
-
Davi Arnaut authored
mysql-test/t/log_tables_debug.test: Remove spurious spaces and disable session debugging.
-
Georgi Kodinov authored
-
Staale Smedseng authored
statements missed from general log A FLUSH LOGS is added to ensure that the log info hits the file before attempting to process. mysql-test/t/log_tables_debug.test: A FLUSH LOGS is added, and in the event that a match is not found, <FILE> is reset and the contents of the log file is dumped for debugging purposes.
-
Georgi Kodinov authored
-