- 14 Jan, 2011 9 commits
-
-
Nirbhay Choubey authored
-
Nirbhay Choubey authored
When mysqldump tries to dump information in xml format, the result does not contain field level comments. In order to retrieve various informations for a field/column, mysqldump currently uses 'show fields from <tab>' statement. The attributes returned by the statement lacks the information regarding field comments. Fixed by changing the query to one that probes I_S to retrieve required field informations, including the field comment. client/mysqldump.c: Bug#13618 : mysqldump --xml omits comment on table field. Replaced the 'show fields' command by a statement that queries I_S, in order to retrieve information on all the attributes that 'show fields' returns along-with an additional column_comment information. mysql-test/r/client_xml.result: Result modifications for bug#13618. mysql-test/r/mysqldump.result: Result modifications for bug#13618. mysql-test/t/mysqldump.test: Added a testcase for bug#13618.
-
Guilhem Bichot authored
mysql-test/r/mysqld--help-notwin.result: consequence of introducing opt_autocommit and its default mysql-test/suite/sys_vars/r/autocommit_func4.result: Before this fix, this test would have shown @@global.autocommit == 0 in spite of --autocommit=on. mysql-test/suite/sys_vars/r/autocommit_func5.result: result unchanged by the fix sql/mysqld.cc: atoi(argument) was reliable for =0|1 parameters. Now that boolean options must support =on/off/true/false, atoi(argument) is wrong (being always 0 for those strings). Instead, let the internal logic of my_getopt (in particular get_bool_argument()) set a boolean opt_autocommit properly, and use that to set global_system_variables.option_bits.
-
Georgi Kodinov authored
The test passes on MacOSX. removing it from the experimental list.
-
Luis Soares authored
-
Sven Sandberg authored
-
Sven Sandberg authored
Backported the fix to 5.1. Problem: the auxiliary test files rpl_start_server.inc and rpl_stop_server.inc write a file that is later read by mtr. The bug was that the file was written with platform-dependent newline terminators, i.e., \r\n on windows, whereas mtr only understands \n. Fix: write the file so that it uses \n on all platforms. mysql-test/include/rpl_start_server.inc: Force test to use \n instead of platform-dependent newline terminator. mysql-test/include/rpl_stop_server.inc: Force test to use \n instead of platform-dependent newline terminator.
-
Georgi Kodinov authored
-
Tor Didriksen authored
Fix: copy my_decimal by value, to avoid dangling pointers. mysql-test/r/func_math.result: New test case. mysql-test/t/func_math.test: New test case. sql/item_cmpfunc.cc: No need to call fix_buffer_pointer() anymore. sql/item_func.cc: Copy my_decimal by value, to avoid dangling pointers. sql/my_decimal.h: Implement proper copy constructor and assignment operator for my_decimal. sql/sql_analyse.cc: No need to call fix_buffer_pointer() anymore. strings/decimal.c: Remove #line directive: it messes up TAGS and it confuses gdb when debugging.
-
- 13 Jan, 2011 9 commits
-
-
Serge Kozlov authored
Bug#58525: separate string and numbers for comparing
-
Luis Soares authored
Added comments to rpl_show_relaylog_events as requested by reviewer.
-
Luis Soares authored
Refactoring effort on test case rpl_show_relaylog_events requested by reviewers.
-
Luis Soares authored
-
Luis Soares authored
-
Nirbhay Choubey authored
null from mysql_store_result. mysqlslap segfaults at a point when it tries to fetch rows from the result set. Under some circumstances, mysql_store_result can return 'NULL', even after query execution (mysql_query) succeeds, and eventually a segfault might occur if same unchecked return value is passed to mysql_fetch_row. Fixed by adding a check on mysql_store_result's return value. client/mysqlslap.c: Bug#59109 : mysqlslap crashes on mysql_fetch_row after ignoring null from mysql_store_result. Added a check on mysql_store_result's return value. A 'NULL' return value here shows an erroneous situation as mysql_field_count has already reported a non-zero value.
-
Georgi Kodinov authored
-
Georgi Kodinov authored
-
Martin Hansson authored
other crashes Some string manipulating SQL functions use a shared string object intended to contain an immutable empty string. This object was used by the SQL function SUBSTRING_INDEX() to return an empty string when one argument was of the wrong datatype. If the string object was then modified by the sql function INSERT(), undefined behavior ensued. Fixed by instead modifying the string object representing the function's result value whenever string manipulating SQL functions return an empty string. Relevant code has also been documented.
-
- 12 Jan, 2011 2 commits
-
-
Bjorn Munch authored
-
Davi Arnaut authored
The problem from a user point of view was that on Solaris the time related functions (e.g. NOW(), SYSDATE(), etc) would always return a fixed time. This bug was happening due to a logic in the time retrieving wrapper function which would only call the time() function every half second. This interval between calls would be calculated using the gethrtime() and the logic relied on the fact that time returned by it is monotonic. Unfortunately, due to bugs in the gethrtime() implementation, there are some cases where the time returned by it can drift (See Solaris bug id 6600939), potentially causing the interval calculation logic to fail. Since newer versions of Solaris (10+) have alleviated the performance degradation associated with time(2), the solution is to simply directly rely on time() at each invocation. This simplification has an upside that it allows us to eliminate a lock which was used to control access to the variables used to track the half second interval, thus improving the overall scalability of timekeeping related functions (e.g. NOW()). Benchmarks runs have shown no significant degradation associated with this change. With this, there are actually improvements in performance for cases involving many connections. In summary, the changes introduced by this patch are: a) my_time() and my_micro_time_and_time() no longer use gethrtime(). Instead, time() and gettimeofdate() are used correspondingly. b) my_micro_time() is changed to not use gethrtime() so as to have the same time source as my_micro_time_and_time(). There shouldn't be any performance impact from this change since this function is used only a few times during statement execution and, on Solaris, gettimeofday() shows acceptable performance. mysys/my_getsystime.c: Use time() even if gethrtime() is available. Remove logic which relied on gethrtime() to only call time() every half second. Since gethrtime() is not used anymore, also remove it from my_micro_time() to keep a common time source. Also, function comments are cleaned up (fixed typos and wrong information) and converted to doxygen. mysys/my_thr_init.c: Remove mutex which is no longer used. mysys/mysys_priv.h: Remove mutex which is no longer used.
-
- 13 Jan, 2011 6 commits
-
-
Ole John Aske authored
Fixed incorrect checks in join_read_const_table() for when to accept a non-existing, or empty const-row as a part of the const'ified set of tables. Intention of this test is to only accept NULL-rows if this table is outer joined into the resultset. (In case of an inner-join we can conclude at this point that resultset will be empty, end we want to return 'error' to signal this.) Initially 'maybe_null' is set to the same value as 'outer_join' in setup_table_map(), mysql_priv.h ~line 2424. Later simplify_joins() will attemp to replace outer joins by inner join whenever possible. This will cause 'outer_join' to be updated. However, 'maybe_null' is *not* updated to reflect this rewrite as this field is used to currectly set the 'nullability' property for the columns in the resultset. We should therefore change join_read_const_table() to check the 'outer_join' property instead of 'maybe_null', as this correctly reflect the nullability of the *execution plan* (not *resultset*).
-
Nirbhay Choubey authored
-
Ole John Aske authored
An incorrect 'table_map' containing both the table itself, and possible any outer-refs if this was the last table in the subquery, was presented to make_cond_for_table(). As a pushed condition is only able to refer column from the table the condition is pushed to, nothing else than columns from the table itself (tab->table->map) may be refered in the pushed condition constructed by 'push_cond= make_cond_for_table()'. Also fix a minor 'copy and paste' bug in a comment inside make_cond_for_table(). No testcase is possible on mainbranch as the NDB engine is not available (yet) on mysql >= 5.5
-
Georgi Kodinov authored
-
Ole John Aske authored
Item_equal::val_int() checked for NULL-values by checking Item::null_value *before* the respective ::store_value() and ::cmp(Item*) metods where called. As Item::null_value is set by these metods, the value of 'null_value' is not valid until *after* ::store_value() or ::cmp() has been called for the Item object. Fix is to swap order of ::store_value()/::cmp() and checking of Item::null_value. This pattern is widely used other places inside item_cmpfunc.cc .
-
Martin Hansson authored
-
- 12 Jan, 2011 14 commits
-
-
Bjorn Munch authored
-
Bjorn Munch authored
-
Luis Soares authored
The test case fails with out of memory while updating a table with several multi-megabytes sized rows. This can probably be too exhausting for PB2 env. The quick fix here is to reduce the size of the biggest row (256MB) so that it becomes a little smaller (64MB).
-
Luis Soares authored
The test started failing on the same day patch for BUG 49978 was pushed. BUG 49978 changed part of the replication testing infrastructure in mysql-test-run. This caused the test to fail sporadically with result differences on relay log file names. When the test fails the relay-log filenames are shifted by one, eg: -show relaylog events in 'slave-relay-bin.000002' from <binlog_start>; +show relaylog events in 'slave-relay-bin.000003' from <binlog_start>; The problem was caused by a bad cleanup when using the include files: - include/setup_fake_relay_log.inc - include/cleanup_fake_relay_log.inc Which would leave a spurious relay-log file around (not listed in slave-relay-bin.index), causing the server to shift the name of the relay logs by one, even if cleaning up with RESET SLAVE. We fix this by removing the relay-log file when it is not needed anymore, ie at setup time and after recreating the fake relay-log index. Additionally, to make the affected test more resilient, we deployed a call to rpl_reset.inc (which resets both master and slave, including log files) before actually running the test case. Finally, appart from the reported bug, we also fix: (a) an unrelated issue with the failing test itself - in some cases, the test was not setting the log file name to use when it should; (b) one typo. mysql-test/extra/rpl_tests/rpl_show_relaylog_events.inc: Added call to rpl_reset.inc. Deployed missing instructions to get the binlog file name before including show_relaylog/binlog_events.inc
-
Evgeny Potemkin authored
-
Bjorn Munch authored
-
Bjorn Munch authored
-
Bjorn Munch authored
-
Dmitry Lenev authored
INVOKER-security view access check wrong" into mysql-5.5 tree.
-
Bjorn Munch authored
Follow-up fix: mtr died if trying to run semisync test w/o the plugin
-
Alexey Botchkov authored
-
Dmitry Lenev authored
INVOKER-security view access check wrong". When privilege checks were done for tables used from an INVOKER-security view which in its turn was used from a DEFINER-security view connection's active security context was incorrectly used instead of security context with privileges of the second view's creator. This meant that users which had enough rights to access the DEFINER-security view and as result were supposed to be able successfully access it were unable to do so in cases when they didn't have privileges on underlying tables of the INVOKER-security view. This problem was caused by the fact that for INVOKER-security views TABLE_LIST::security_ctx member for underlying tables were set to 0 even in cases when particular view was used from another DEFINER-security view. This meant that when checks of privileges on these underlying tables was done in setup_tables_and_check_access() active connection security context was used instead of context corresponding to the creator of caller view. This fix addresses the problem by ensuring that underlying tables of an INVOKER-security view inherit security context from the view and thus correct security context is used for privilege checks on underlying tables in cases when such view is used from another view with DEFINER-security. mysql-test/r/view_grant.result: Added coverage for various combinations of DEFINER and INVOKER-security views, including test for bug #58499 "DEFINER-security view selecting from INVOKER-security view access check wrong". mysql-test/t/view_grant.test: Added coverage for various combinations of DEFINER and INVOKER-security views, including test for bug #58499 "DEFINER-security view selecting from INVOKER-security view access check wrong". sql/sql_view.cc: When opening a non-suid view ensure that its underlying tables will get the same security context as use for checking privileges on the view, i.e. security context of view invoker. This context can be different from the security context which is currently active for connection in cases when this non-suid view is used from a view with suid security. Inheriting security context in such situation allows correctly apply privileges of creator of suid view in checks for tables of non-suid view (since in this situation creator/definer of suid view serves as invoker for non-suid view).
-
Alexey Botchkov authored
Item_func_spatial_collection::fix_length_and_dec didn't call parent's method, so the maybe_null was set to '0' after it. But in this case the result was just NULL, that caused wrong behaviour. per-file comments: mysql-test/r/gis.result Bug #57321 crashes and valgrind errors from spatial types test result updated. mysql-test/t/gis.test Bug #57321 crashes and valgrind errors from spatial types test case added. sql/item_geofunc.h Bug #57321 crashes and valgrind errors from spatial types Item_func_geometry::fix_length_and_dec() called in Item_func_spatial_collection::fix_length_and_dec().
-
Evgeny Potemkin authored
TIMESTAMP. Item_cache::get_cache wasn't treating TIMESTAMP as a DATETIME value thus returning string cache for items with TIMESTAMP type. This led to incorrect TIMESTAMP -> INT conversion and to a wrong query result. Fixed by using Item::is_datetime function to check for DATETIME type group. mysql-test/r/type_timestamp.result: Added a test case for the bug#59330. mysql-test/t/type_timestamp.test: Added a test case for the bug#59330. sql/item.cc: Bug#59330: Incorrect result when comparing an aggregate function with TIMESTAMP. Item_cache::get_cache now uses is_datetime member function to detect DATETIME type group.
-