- 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.
-
- 01 Aug, 2009 1 commit
-
-
- 31 Jul, 2009 11 commits
-
-
Jim Winstead authored
-
Jim Winstead authored
-
Davi Arnaut authored
engine to the partition_csv test. Also remove test case that was duplicated. Fix connection procedure with the embedded server.
-
Ignacio Galarza authored
-
Tatiana A. Nurnberg authored
-
Ignacio Galarza authored
-
Ignacio Galarza authored
- Define and pass compile time path variables as pre-processor definitions to mimic the makefile build. - Set new CMake version and policy requirements explicitly. - Changed DATADIR to MYSQL_DATADIR to avoid conflicting definition in Platform SDK header ObjIdl.h which also defines DATADIR.
-
Gleb Shchepa authored
when used with --tab 1) New syntax: added CHARACTER SET clause to the SELECT ... INTO OUTFILE (to complement the same clause in LOAD DATA INFILE). mysqldump is updated to use this in --tab mode. 2) ESCAPED BY/ENCLOSED BY field parameters are documented as accepting CHAR argument, however SELECT .. INTO OUTFILE silently ignored rests of multisymbol arguments. For the symmetrical behavior with LOAD DATA INFILE the server has been modified to fail with the same error: ERROR 42000: Field separator argument is not what is expected; check the manual 3) Current LOAD DATA INFILE recognizes field/line separators "as is" without converting from client charset to data file charset. So, it is supposed, that input file of LOAD DATA INFILE consists of data in one charset and separators in other charset. For the compatibility with that [buggy] behaviour SELECT INTO OUTFILE implementation has been saved "as is" too, but the new warning message has been added: Non-ASCII separator arguments are not fully supported This message warns on field/line separators that contain non-ASCII symbols.
-
Davi Arnaut authored
If using statement based replication (SBR), repeatedly calling statements which are unsafe for SBR will cause a warning message to be written to the error for each statement. This might lead to filling up the error log and there is no way to disable this behavior. The solution is to only log these message (about statements unsafe for statement based replication) if the log_warnings option is set. For example: SET GLOBAL LOG_WARNINGS = 0; INSERT INTO t1 VALUES(UUID()); SET GLOBAL LOG_WARNINGS = 1; INSERT INTO t1 VALUES(UUID()); In this case the message will be printed only once: [Warning] Statement may not be safe to log in statement format. Statement: INSERT INTO t1 VALUES(UUID())
-
Tatiana A. Nurnberg authored
We disallow the partitioning of a log table. You could however partition a table first, and then point logging to it. This is not only against the docs, it also crashes the server. We catch this case now.
-
Jim Winstead authored
-
- 30 Jul, 2009 1 commit
-
-
Davi Arnaut authored
Initialize LOCK_open as a adapative mutex on platforms where the PTHREAD_ADAPTIVE_MUTEX_INITIALIZER_NP macro is available. The flag indicates that a thread should spin (busy wait) for some time on a locked adaptive mutex before blocking (sleeping). It's intended to to alleviate performance problems due to LOCK_open being a highly contended mutex.
-
- 31 Jul, 2009 1 commit
-
-
V Narayanan authored
-
- 30 Jul, 2009 7 commits
-
-
Matthias Leich authored
-
Matthias Leich authored
-
Davi Arnaut authored
-
Matthias Leich authored
-
Matthias Leich authored
-
Matthias Leich authored
-
V Narayanan authored
A REPLACE in the MERGE engine is actually a REPLACE into one (FIRST or LAST) of the underlying MyISAM tables. So in effect the server works on the meta data of the MERGE table, while the real insert happens in the MyISAM table. The MERGE table has no index, while MyISAM has a unique index. When a REPLACE into a MERGE table ( and the REPLACE conflicts with a duplicate in a child table) is done, we try to access the duplicate key information for the MERGE table. This information actually does not exist, hence this results in a crash. The problem can be resolved by modifying the MERGE engine to provide us the duplicate key information directly, instead of just returning the MyISAM index number as the error key. Then the SQL layer (or "the server") does not try to access the key_info of the MERGE table, which does not exist. The current patch modifies the MERGE engine to provide the position for a record where a unique key violation occurs.
-
- 29 Jul, 2009 7 commits
-
-
Kristofer Pettersson authored
Fixed wrong prototype declaration which cased build failure on solaris.
-
Kristofer Pettersson authored
-
Kristofer Pettersson authored
an assertion in a debug build. The reason is that the C API doesn't support multiple result sets for prepared statements and attempting to execute a stored routine which returns multiple result sets sometimes lead to a network error. The network error sets the diagnostic area prematurely which later leads to the assert when an attempt is made to set a second server state. This patch fixes the issue by changing the scope of the error code returned by sp_instr_stmt::execute() to include any error which happened during the execution. To assure that Diagnostic_area::is_sent really mean that the message was sent all network related functions are checked for return status.
-
Mikael Ronstrom authored
-
Mikael Ronstrom authored
Bug#46354, when defining partitions without subpartition definition after defining it with the first partition and using list partition caused crash, fixed by more error checks in parser
-
Guilhem Bichot authored
-
Guilhem Bichot authored
those keywords do nothing in 5.1 (they are meant for future versions, for example featuring the Maria engine) so they are here removed from the syntax. Adding those keywords to future versions when needed is: - WL#5034 "Add TRANSACTIONA=0|1 and PAGE_CHECKSUM=0|1 clauses to CREATE TABLE" - WL#5037 "New ROW_FORMAT value for CREATE TABLE: PAGE"
-
- 28 Jul, 2009 8 commits
-
-
Alfranio Correia authored
-
Davi Arnaut authored
consumption (CPU) for upgrading a large log table can be intense. Therefore, truncate the general_log table beforehand if running mysql_upgrade test with Valgrind.
-
Alexey Kopytov authored
-
Alexey Kopytov authored
-
Alexey Kopytov authored
-
Alexey Kopytov authored
-
Alexey Kopytov authored
compression Since uint3korr() may read 4 bytes depending on build flags and platform, allocate 1 extra "safety" byte in the network buffer for cases when uint3korr() in my_real_read() is called to read last 3 bytes in the buffer. It is practically hard to construct a reliable and reasonably small test case for this bug as that would require constructing input stream such that a certain sequence of bytes in a compressed packet happens to be the last 3 bytes of the network buffer.
-
Alfranio Correia authored
If the log_bin_trust_function_creators option is not defined, creating a stored function requires either one of the modifiers DETERMINISTIC, NO SQL, or READS SQL DATA. Executing a stored function should also follows the same rules if in STATEMENT mode. However, this was not happening and a wrong error was being printed out: ER_BINLOG_ROW_RBR_TO_SBR. The patch makes the creation and execution compatible and prints out the correct error ER_BINLOG_UNSAFE_ROUTINE when a stored function without one of the modifiers above is executed in STATEMENT mode.
-
- 27 Jul, 2009 3 commits
-
-
Davi Arnaut authored
The maximum value of the max_join_size variable is set by converting a signed type (long int) with negative value (-1) to a wider unsigned type (unsigned long long), which yields the largest possible value of the wider unsigned type -- as per the language conversion rules. But, depending on build options, the type of the max_join_size might be a shorter type (ha_rows - unsigned long) which causes the warning to be thrown once the large value is truncated to fit. The solution is to ensure that the maximum value of the variable is always set to the maximum value of integer type of max_join_size. Furthermore, it would be interesting to always have a fixed type for this variable, but this would incur in a change of behavior which is not acceptable for a GA version. See Bug#35346.
-
Davi Arnaut authored
during bootstrap on a embedded server.
-
Davi Arnaut authored
-