- 17 Nov, 2010 3 commits
-
-
Tor Didriksen authored
-
Davi Arnaut authored
-
Davi Arnaut authored
Use __builtin_stpcpy only if the system supports stpcpy. This is necessary as in some cases a call to stpcpy will be emitted if the built-in can not optimized.
-
- 16 Nov, 2010 8 commits
-
-
Mats Kindahl authored
-
Mats Kindahl authored
-
Mats Kindahl authored
Memory was allocated for storing path names inside fn_expand(), which were not free:ed anywhere. This patch fixes the problem by storing the path names in statically allocated buffers instead, which is automatically free:ed when the server exits.
-
Davi Arnaut authored
-
Marc Alff authored
-
Marc Alff authored
-
Mattias Jonsson authored
-
Mattias Jonsson authored
Including adding test in 5.5 requiring --big-test flag from mysql-test-run.pl and also disabled tests that fails.
-
- 15 Nov, 2010 6 commits
-
-
Mattias Jonsson authored
-
Mattias Jonsson authored
-
Mattias Jonsson authored
-
Mattias Jonsson authored
-
Jorgen Loland authored
during EXPLAIN Before the patch, send_eof() of some subclasses of select_result (e.g., select_send::send_eof()) could handle being called after an error had occured while others could not. The methods that were not well-behaved would trigger an ASSERT on debug builds. Release builds were not affected. Consider the following query as an example for how the ASSERT could be triggered: A user without execute privilege on f() does SELECT MAX(key1) INTO @dummy FROM t1 WHERE f() < 1; resulting in "ERROR 42000: execute command denied to user..." The server would end the query by calling send_eof(). The fact that the error had occured would make the ASSERT trigger. select_dumpvar::send_eof() was the offending method in the bug report, but the problem also applied to other subclasses of select_result. This patch uniforms send_eof() of all subclasses of select_result to handle being called after an error has occured.
-
Mattias Jonsson authored
The test result differs on windows, since it writes out 'localhost:<port>' instead of only 'localhost', since it uses tcp/ip instead of unix sockets on windows. Fixed by replacing that column. Also requires --big-test from some long running tests and added a weekly run of all test requiring --big-test.
-
- 13 Nov, 2010 4 commits
-
-
Vladislav Vaintroub authored
-
Vladislav Vaintroub authored
-
Vladislav Vaintroub authored
Problem: with "make package" , many small packages are generated, one per CMake COMPONENT, instead of expected single package. This is due to the new (in cmake 2.8.3) component-based install for archive( e.g ZIP,TGZ ) CPack generators. See http://public.kitware.com/Bug/view.php?id=11452 for discussion. Fix: use CPACK_MONOLITHIC_INSTALL=1 to enforce single package. Reset this variable temporarily to 0 for MSI creation (MSI needs COMPONENTs)
-
Alexander Nozdrin authored
structure buffer). This is a follow-up for WL#4435. The bug actually existed not only MYSQL_TYPE_DATETIME type. The problem was that Item_param::set_value() was written in an assumption that it's working with expressions, i.e. with basic data types. There are two different quick fixes here: a) Change Item_param::make_field() -- remove setting of Send_field::length, Send_field::charsetnr, Send_field::flags and Send_field::type. That would lead to marshalling all data using basic types to the client (MYSQL_TYPE_LONGLONG, MYSQL_TYPE_DOUBLE, MYSQL_TYPE_STRING and MYSQL_TYPE_NEWDECIMAL). In particular, that means, DATETIME would be sent as MYSQL_TYPE_STRING, TINYINT -- as MYSQL_TYPE_LONGLONG, etc. That could be Ok for the client, because the client library does reverse conversion automatically (the client program would see DATETIME as MYSQL_TIME object). However, there is a problem with metadata -- the metadata would be wrong (misleading): it would say that DATETIME is marshaled as MYSQL_TYPE_DATETIME, not as MYSQL_TYPE_STRING. b) Set Item_param::param_type properly to actual underlying field type. That would lead to double conversion inside the server: for example, MYSQL_TIME-object would be converted into STRING-object (in Item_param::set_value()), and then converted back to MYSQL_TIME-object (in Item_param::send()). The data however would be marshalled more properly, and also metadata would be correct. This patch implements b). There is also a possibility to avoid double conversion either by clonning the data field, or by storing a reference to it and using it on Item::send() time. That requires more work and might be done later.
-
- 12 Nov, 2010 5 commits
-
-
Joerg Bruehe authored
MySQL-shared RPM no longer provides mysql-shared The spec file is changed to explicitly "provide" "mysql-shared" by the "shared" sub-RPM.
-
Vladislav Vaintroub authored
Backport version info handling (Windows-specific) from next-mr. Instead of adding ".res" object as linker flag, add resource file (.rc) file to the source list. This is more obvious and less error prone method.
-
Marc Alff authored
Before this fix, file io for the binary log file was not accounted properly, and showed no io at all. This bug was due to the following issues: 1) file io for the binlog was instrumented: - sometime as "wait/io/file/sql/binlog" - sometime as "wait/io/file/sql/MYSQL_LOG" leading to inconsistent event_names. 2) the binlog file itself was using an IO_CACHE, but the IO_CACHE implementation in mysys/mf_iocache.c was not instrumented to make performance schema calls to record file io. 3) The "wait/io/file/sql/MYSQL_LOG" instrumentation was used for several log files, such as: - the binary log - the slow log - the query log which caused file io in these different log files to be accounted against the same instrument. The instrumentation needs to have a finer grain and report io in different event_names, because each file really serves a different purpose. With this fix: - the IO_CACHE implementation is now instrumented - the "wait/io/file/sql/MYSQL_LOG" instrument has been removed - binlog io is now always instrumented with "wait/io/file/sql/binlog" - the slow log is instrumented with a new name, "wait/io/file/sql/slow_log" - the query log is instrumented with a new name, "wait/io/file/sql/query_log"
-
Vladislav Vaintroub authored
-
Vladislav Vaintroub authored
--with-comment correctly Properly convert --with-comment do not uppercase it, quote as it might contain spaces.
-
- 11 Nov, 2010 8 commits
-
-
Sunanda Menon authored
-
Sunanda Menon authored
( Based on review comments)
-
Marc Alff authored
This fix is a follow up on the fix for similar issue 56761. When sanitizing data read from the events_waits_history_long table, the code needs also to sanitize the schema_name / object_name / file_name pointers, because such pointers could also hold invalid values. Checking the string length alone was required but not sufficient. This fix verifies that: - the table schema and table name used in table io events - the file name used in file io events are valid pointers before dereferencing these pointers.
-
Mattias Jonsson authored
with on duplicate key update There was a missed corner case in the partitioning handler, which caused the next_insert_id to be changed in the second level handlers (i.e the hander of a partition), which caused this debug assertion. The solution was to always ensure that only the partitioning level generates auto_increment values, since if it was done within a partition, it may fail to match the partition function.
-
Sergey Vojtovich authored
-
Sergey Vojtovich authored
-
Dmitry Shulga authored
-
Dmitry Shulga authored
in different default schema. In strict mode, when data truncation or conversion happens, THD::killed is set to THD::KILL_BAD_DATA. This is abuse of KILL mechanism to guarantee that execution of statement is aborted. The stored procedures execution, on the other hand, upon detection that a connection was killed, would terminate immediately, without trying to restore the caller's context, in particular, restore the caller's current schema. The fix is, when terminating a stored procedure execution, to only bypass cleanup if the entire connection was killed, not in case of other forms of KILL.
-
- 10 Nov, 2010 6 commits
-
-
Davi Arnaut authored
Bug#57995: Compiler flag change build error on OSX 10.4: my_getncpus.c Bug#57996: Compiler flag change build error on OSX 10.5 : bind.c Bug#57994: Compiler flag change build error : my_redel.c Bug#57993: Compiler flag change build error on FreeBsd 7.0 : regexec.c Bug#57992: Compiler flag change build error on FreeBsd : mf_keycache.c Bug#57997: Compiler flag change build error on OSX 10.6: debug_sync.cc Fix assorted compiler generated warnings.
-
Vladislav Vaintroub authored
-
Georgi Kodinov authored
-
Georgi Kodinov authored
- added missing DBUG_RETURN - fixed whitespace according to coding style.
-
Oystein Grovlen authored
This bug was introduced in this revision: kostja@sun.com-20100727102553-b4n2ojcyfj79l2x7 ("A pre-requisite patch for the fix for Bug#52044.") It happens because close_thread_tables() is now called in open_and_lock_tables upon failure. Hence, table is no longer open when optimizer tries to do cleanup. Fix: Make sure to do cleanup in st_select_lex_unit::prepare() upon failure. This way, cleanup() is called before tables are released.
-
Dmitry Shulga authored
-