- 12 Jan, 2011 10 commits
-
-
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
-
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).
-
Ole John Aske authored
If the ::single_value_transformer() find an existing HAVING condition it used to do the transformation: 1) HAVING cond -> (HAVING Cond) AND (cond_guard (Item_ref_null_helper(...)) As the AND condition in 1) is Mc'Carty evaluated, the right side of the AND cond should be executed only if the original 'HAVING evaluated' to true. However, as we failed to set 'top_level' for the tranformed HAVING condition, 'abort_on_null' was FALSE after transformation. An UNKNOWN having condition will then not terminate evaluation of the transformed having condition, and we incorrectly continued into the Item_ref_null_helper() part.
-
Martin Hansson authored
-
Bjorn Munch authored
New patch, avoid global $opt_parallel I still prefer not to print workerid when not doing parallel
-
Martin Hansson authored
tmptable needed The function DEFAULT() works by modifying the the data buffer pointers (often referred to as 'record' or 'table record') of its argument. This modification is done during name resolution (fix_fields().) Unfortunately, the same modification is done when creating a temporary table, because default values need to propagate to the new table. Fixed by skipping the pointer modification for fields that are arguments to the DEFAULT function.
-
- 11 Jan, 2011 16 commits
-
-
Dmitry Shulga authored
-
Dmitry Shulga authored
if max_allowed_packet >= 16M. This bug was introduced by patch for bug#42503. This patch restores behaviour that there was before patch for bug#42503 was applied. sql/net_serv.cc: Restored original right condition.
-
Bjorn Munch authored
Local variable ds_warnings in run_query not cleared. But when we call die() we don't have access to it. Set global var. to point to it when allocated.
-
Bjorn Munch authored
Test name spec would be cut at last / Only do this when .test file name given, not suite.<test>
-
Bjorn Munch authored
-
Bjorn Munch authored
Followup: had forgotten to update mysqltest.test due to changed output - duh!
-
Davi Arnaut 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. The solution is to retrieve the correct time whenever a drift in the time returned by gethrtime() is detected. That is, do not use the cached time whenever the values (previous and current) returned by gethrtime() are not monotonically increasing. mysys/my_getsystime.c: Do not used the cached time if gethrtime is not monotonic.
-
Bjorn Munch authored
Put descriptions of plugins into a separate file read by MTR MTR itself has generalised code to read this and set env. variables Removed the *SO variables, updated some tests accordingly New commit: added optional list of plugin names for _LOAD variable Also made changes for the new AUTH_* plugins
-
Jan Wedvik authored
extended' to crash mysqld" (see http://lists.mysql.com/commits/128409).
-
Jan Wedvik authored
to crash mysqld". handler::pushed_cond was not always properly reset when table objects where recycled via the table cache. handler::pushed_cond is now set to NULL in handler::ha_reset(). This should prevent pushed conditions from (incorrectly) re-apperaring in later queries.
-
Bjorn Munch authored
Generalized fix for recursive backtick Optional arg to eval_expr telling it not to interpret
-
Bjorn Munch authored
Added a pattern match to cover combinations Added to readme file
-
Bjorn Munch authored
This patchs adds printing of a file stack (with line numbers) It does not fix the problem of a failure in the non-first iteration of a loop
-
Magne Mahre authored
and 'THREAD_SAFE_CLIENT'. As of MySQL 5.5, we no longer support non-threaded builds. This patch removes all references to the obsolete THREAD and THREAD_SAFE_CLIENT preprocessor symbols. These were used to distinguish between threaded and non-threaded builds.
-
Anitha Gopi authored
-
- 10 Jan, 2011 13 commits
-
-
Mattias Jonsson authored
-
Mattias Jonsson authored
-
Matthias Leich authored
Remove the test from defaults.experimental.
-
Magne Mahre authored
the my.cnf, works as command Different parsing mechanisms are used for command line/my.cnf options and the SQL commands. The former only accepted numeric arguments, and regarded all numbers different from 0 as 'true'. Any other argument was parsed as 'false' . This patch adds the words 'true' and 'on' as valid truth values for boolean option arguments. A test case is not provided, as the fix is simple and does not warrant a separate test file (no existing suitable test file was found) (backported from mysql-trunk)
-
Mattias Jonsson authored
-
Jon Olav Hauglid authored
OPTIMIZE TABLE OPTIMIZE TABLE for InnoDB tables is handled as recreate + analyze. The triggered assert checked that an error had been reported if either recreate or analyze failed. However the assert failed to take into account that they could have failed because OPTIMIZE TABLE had been victim of KILL QUERY, KILL CONNECTION or server shutdown. This patch adjusts the assert to take this possibility into account. The problem was only noticeable on debug versions of the server. Test case added to innodb_mysql_sync.test.
-
Magne Mahre authored
and Order By When having a UNION statement in a subquery, with no referenced tables (or only a reference to the virtual table 'dual'), the UNION did not allow an ORDER BY clause. i.e: SELECT(SELECT 1 AS a UNION SELECT 0 AS a ORDER BY a) AS b or SELECT(SELECT 1 AS a FROM dual UNION SELECT 0 as a ORDER BY a) AS b In addition, an ORDER BY / LIMIT clause was not accepted in subqueries even for single SELECT statements with no referenced tables (or with 'dual' as table reference) i.e: SELECT(SELECT 1 AS a ORDER BY a) AS b or SELECT(SELECT 1 AS a FROM dual ORDER BY a) AS b The fix was to allow an optional ORDER BY/LIMIT clause to the grammar for these cases. See also: Bug#57986
-
Magne Mahre authored
if embedded in a SELECT An ORDER BY clause was bound to the incorrect (sub-)statement when used in a UNION context. In a query like: SELECT * FROM a UNION SELECT * FROM b ORDER BY c the result of SELECT * FROM b is sorted, and then combined with a. The correct behaviour is that the ORDER BY clause should be applied on the final set. Similar behaviour was seen on LIMIT clauses as well. In a UNION statement, there will be a select_lex object for each of the two selects, and a select_lex_unit object that describes the UNION itself. Similarly, the same behaviour was also seen on derived tables. The bug was caused by using a grammar rule for ORDER BY and LIMIT that bound these elements to thd->lex->current_select, which points to the last of the two selects, instead of to the fake_select_lex member of the master select_lex_unit object. sql/sql_yacc.yy: Need to use (opt_)union_order_or_limit to bind to the correct select_lex object.
-
Mattias Jonsson authored
-
Mattias Jonsson authored
-
Bjorn Munch authored
-
Bjorn Munch authored
-
Bjorn Munch authored
-
- 08 Jan, 2011 1 commit
-
-
Vasil Dimov authored
-