- 09 Jul, 2009 1 commit
-
-
Georgi Kodinov authored
When the function exits with an error it was not freeing the local Unique class instance. Fixed my making sure all the places where the function returns from are freeing the Unique instance
-
- 19 Aug, 2009 2 commits
-
-
Georgi Kodinov authored
-
Georgi Kodinov authored
-
- 17 Aug, 2009 3 commits
-
-
Georgi Kodinov authored
-
Georgi Kodinov authored
-
Georgi Kodinov authored
-
- 14 Aug, 2009 1 commit
-
-
Ramil Kalimullin authored
-
- 13 Aug, 2009 4 commits
-
-
Davi Arnaut authored
-
Davi Arnaut authored
Bug#45243: crash on win in sql thread clear_tables_to_lock() -> free() Bug#45242: crash on win in mysql_close() -> free() Bug#45238: rpl_slave_skip, rpl_change_master failed (lost connection) for STOP SLAVE Bug#46030: rpl_truncate_3innodb causes server crash on windows Bug#46014: rpl_stm_reset_slave crashes the server sporadically in pb2 When killing a user session on the server, it's necessary to interrupt (notify) the thread associated with the session that the connection is being killed so that the thread is woken up if waiting for I/O. On a few platforms (Mac, Windows and HP-UX) where the SIGNAL_WITH_VIO_CLOSE flag is defined, this interruption procedure is to asynchronously close the underlying socket of the connection. In order to enable this schema, each connection serving thread registers its VIO (I/O interface) so that other threads can access it and close the connection. But only the owner thread of the VIO might delete it as to guarantee that other threads won't see freed memory (the thread unregisters the VIO before deleting it). A side note: closing the socket introduces a harmless race that might cause a thread attempt to read from a closed socket, but this is deemed acceptable. The problem is that this infrastructure was meant to only be used by server threads, but the slave I/O thread was registering the VIO of a mysql handle (a client API structure that represents a connection to another server instance) as a active connection of the thread. But under some circumstances such as network failures, the client API might destroy the VIO associated with a handle at will, yet the VIO wouldn't be properly unregistered. This could lead to accesses to freed data if a thread attempted to kill a slave I/O thread whose connection was already broken. There was a attempt to work around this by checking whether the socket was being interrupted, but this hack didn't work as intended due to the aforementioned race -- attempting to read from the socket would yield a "bad file descriptor" error. The solution is to add a hook to the client API that is called from the client code before the VIO of a handle is deleted. This hook allows the slave I/O thread to detach the active vio so it does not point to freed memory.
-
Ramil Kalimullin authored
on SHOW CREATE TRIGGER + MERGE table Problem: SHOW CREATE TRIGGER erroneously relies on fact that we have the only underlying table for a trigger (wrong for merge tables). Fix: remove erroneous assert().
-
There is an inconsistency with DROP DATABASE|TABLE|EVENT IF EXISTS and CREATE DATABASE|TABLE|EVENT IF NOT EXISTS. DROP IF EXISTS statements are binlogged even if either the DB, TABLE or EVENT does not exist. In contrast, Only the CREATE EVENT IF NOT EXISTS is binlogged when the EVENT exists. This patch fixes the following cases for all the replication formats: CREATE DATABASE IF NOT EXISTS. CREATE TABLE IF NOT EXISTS, CREATE TABLE IF NOT EXISTS ... LIKE, CREAET TABLE IF NOT EXISTS ... SELECT.
-
- 12 Aug, 2009 11 commits
-
-
Alexander Nozdrin authored
-
Alexander Nozdrin authored
-
Mattias Jonsson authored
-
karen.langford@sun.com authored
-
Konstantin Osipov authored
"CREATE TABLE TRANSACTIONAL PAGE_CHECKSUM ROW_FORMAT=PAGE accepted, does nothing". Put back stubs for members of structures that are shared between sql/ and pluggable storage engines. to not break ABI unnecessarily. To be NULL-merged into 5.4, where we do break the ABI already.
-
Sergey Vojtovich authored
not ready to run with innoplug-1.0.4.
-
Konstantin Osipov authored
PAGE_CHECKSUM ROW_FORMAT=PAGE accepted, does nothing" Remove unused code that would lead to warnings when compiling sql_yacc.yy.
-
Mattias Jonsson authored
-
Mattias Jonsson authored
-
Replication SQL thread does not set database default charset to thd->variables.collation_database properly, when executing LOAD DATA binlog. This bug can be repeated by using "LOAD DATA" command in STATEMENT mode. This patch adds code to find the default character set of the current database then assign it to thd->db_charset when slave server begins to execute a relay log. The test of this bug is added into rpl_loaddata_charset.test
-
- 11 Aug, 2009 10 commits
-
-
Davi Arnaut authored
-
Davi Arnaut authored
-
Davi Arnaut authored
-
Davi Arnaut authored
-
Vladislav Vaintroub authored
-
Vladislav Vaintroub authored
widely used, in replication (delete_allow_opened) and for named pipe support. We do not support Win9x anymore.
-
Davi Arnaut authored
-
Davi Arnaut authored
-
Sergey Vojtovich authored
-
sunanda.menon@sun.com authored
-
- 10 Aug, 2009 4 commits
-
-
Davi Arnaut authored
-
hery.ramilison@sun.com authored
-
Davi Arnaut authored
-
Martin Hansson authored
-
- 08 Aug, 2009 1 commit
-
-
Davi Arnaut authored
The problem is that the lexer could inadvertently skip over the end of a query being parsed if it encountered a malformed multibyte character. A specially crated query string could cause the lexer to jump up to six bytes past the end of the query buffer. Another problem was that the laxer could use unfiltered user input as a signed array index for the parser maps (having upper and lower bounds 0 and 256 respectively). The solution is to ensure that the lexer only skips over well-formed multibyte characters and that the index value of the parser maps is always a unsigned value.
-
- 07 Aug, 2009 1 commit
-
-
Martin Hansson authored
Problem 1: When the 'Using index' optimization is used, the optimizer may still - after cost-based optimization - decide to use another index in order to avoid using a temporary table. But when this happens, the flag to the storage engine to read index only (not table) was still set. Fixed by resetting the flag in the storage engine and TABLE structure in the above scenario, unless the new index allows for the same optimization. Problem 2: When a 'ref' access method was employed by cost-based optimizer, (when the column is non-NULLable), it was assumed that it needed no initialization if 'quick' access methods (since they are based on range scan). When ORDER BY optimization overrides the decision, however, it expects to have this initialized and hence crashes. Fixed in 5.1 (was fixed in 6.0 already) by initializing 'quick' even when there's 'ref' access.
-
- 06 Aug, 2009 2 commits
-
-
Ignacio Galarza authored
-
Ignacio Galarza authored
- Remove offensive quotes.
-