INSERT IGNORE ... SELECT ... UNION SELECT ...
This assert was triggered by INSERT IGNORE ... SELECT. The assert checks that a
statement either sends OK or an error to the client. If the bug was triggered
on release builds, it caused OK to be sent to the client instead of the correct
error message (in this case ER_FIELD_SPECIFIED_TWICE).
The reason the assert was triggered, was that lex->no_error was set to TRUE
during JOIN::optimize() because of IGNORE. This causes all errors to be ignored.
However, not all errors can be ignored. Some, such as ER_FIELD_SPECIFIED_TWICE
will cause the INSERT to fail no matter what. But since lex->no_error was set,
the critical errors were ignored, the INSERT failed and neither OK nor the
error message was sent to the client.
This patch fixes the problem by temporarily turning off lex->no_error in
places where errors cannot be ignored during processing of INSERT ... SELECT.
Test case added to insert.test.
DELETE statement
Single-table delete ordered by a field that has a hash-type index
may cause an assertion failure or a crash.
An optimization added by the fix for the bug 36569 forced the
optimizer to use ORDER BY-compatible indices when applicable.
However, the existence of unsorted indices (HASH index algorithm
for some engines such as MEMORY/HEAP, NDB) was ignored.
The test_if_order_by_key function has been modified to skip
unsorted indices.
mysql-test/r/heap_hash.result:
Test case for bug #55472.
mysql-test/t/heap_hash.test:
Test case for bug #55472.
sql/sql_select.cc:
Bug #55472: Assertion failed in heap_rfirst function of hp_rfirst.c on
DELETE statement
The test_if_order_by_key function has been modified to skip
unsorted indices.
Remove dead and unused code.
Update to reflect the code review requests.
include/thr_lock.h:
Remove declarations for THR_LOCK_OWNER,
added along with the patch for sensitive cursors.
mysys/thr_lock.c:
Remove support for multiple thr_lock requestors
per THD.
sql/lock.cc:
Revert the patch that added support for sensitive cursors.
sql/sp_rcontext.cc:
Updated the use of mysql_open_cursor().
sql/sql_class.cc:
Move the instance of Server_side_cursor
from class Prepared_statement to class Statement.
sql/sql_class.h:
Move the isntance of Server_side_cursor
from class Prepared_statement to class
Statement.
Remove multiple lock_ids of thr_lock.
sql/sql_cursor.cc:
Remove Sensitive_cursor implementation.
sql/sql_cursor.h:
Remove declarations for sensitive cursors.
sql/sql_prepare.cc:
Move the declaration of instance of Server_side_cursor
from class Statement to class Prepared_statement,
where it's used.
sql/sql_select.cc:
Remove sensitive cursor support.
sql/sql_select.h:
Remove sensitive cursor support.
sql/sql_union.cc:
Remove sensitive cursor support.
This assert checks that the server does not try to send OK to the
client if there has been some error during processing. This is done
to make sure that the error is in fact sent to the client.
The problem was that view errors during processing of WHERE conditions
in UPDATE statements where not detected by the update code. It therefore
tried to send OK to the client, triggering the assert.
The bug was only noticeable in debug builds.
This patch fixes the problem by making sure that the update code
checks for errors during condition processing and acts accordingly.
The problem there is that HAVING condition evaluates const
parts of condition despite the condition has references
on aggregate functions. Table t1 became const tables
after make_join_statistics and table1.pk = 1, HAVING is
transformed into MAX(1) < 7 and taken away from HAVING.
The fix is to skip evaluation of HAVING conts parts if
HAVING condition has references on aggregate functions.
mysql-test/r/having.result:
test case
mysql-test/t/having.test:
test case
sql/sql_select.cc:
skip evaluation of HAVING conts parts if
HAVING condition has references on aggregate functions.
Essentially, the problem is that safemalloc is excruciatingly
slow as it checks all allocated blocks for overrun at each
memory management primitive, yielding a almost exponential
slowdown for the memory management functions (malloc, realloc,
free). The overrun check basically consists of verifying some
bytes of a block for certain magic keys, which catches some
simple forms of overrun. Another minor problem is violation
of aliasing rules and that its own internal list of blocks
is prone to corruption.
Another issue with safemalloc is rather the maintenance cost
as the tool has a significant impact on the server code.
Given the magnitude of memory debuggers available nowadays,
especially those that are provided with the platform malloc
implementation, maintenance of a in-house and largely obsolete
memory debugger becomes a burden that is not worth the effort
due to its slowness and lack of support for detecting more
common forms of heap corruption.
Since there are third-party tools that can provide the same
functionality at a lower or comparable performance cost, the
solution is to simply remove safemalloc. Third-party tools
can provide the same functionality at a lower or comparable
performance cost.
The removal of safemalloc also allows a simplification of the
malloc wrappers, removing quite a bit of kludge: redefinition
of my_malloc, my_free and the removal of the unused second
argument of my_free. Since free() always check whether the
supplied pointer is null, redudant checks are also removed.
Also, this patch adds unit testing for my_malloc and moves
my_realloc implementation into the same file as the other
memory allocation primitives.
client/mysqldump.c:
Pass my_free directly as its signature is compatible with the
callback type -- which wasn't the case for free_table_ent.
The problem is that QUICK_SELECT_DESC behaviour depends
on used_key_parts value which can be bigger than selected
best_key_parts value if an engine supports clustered key.
But used_key_parts is overwritten with best_key_parts
value that prevents from correct selection of index
access method. The fix is to preserve used_key_parts
value for further use in QUICK_SELECT_DESC.
mysql-test/r/innodb_mysql.result:
test case
mysql-test/t/innodb_mysql.test:
test case
sql/sql_select.cc:
preserve used_key_parts value for further use in QUICK_SELECT_DESC
file .\filesort.cc, line 149 (part II)
Problem: the server didn't disregard sort order
for some zero length tuples.
Fix: skip sort order in such a case
(zero length NOT NULL string functions).
mysql-test/r/select.result:
Fix for bug #54459: Assertion failed: param.sort_length,
file .\filesort.cc, line 149 (part II)
- test result.
mysql-test/t/select.test:
Fix for bug #54459: Assertion failed: param.sort_length,
file .\filesort.cc, line 149 (part II)
- test case.
sql/sql_select.cc:
Fix for bug #54459: Assertion failed: param.sort_length,
file .\filesort.cc, line 149 (part II)
- disregard sort order for zero length NOT NULL string functions
along with zero length NOT NULL fields.
Don't call member functions for a NIL pointer.
mysql-test/r/subselect4.result:
Add test case.
mysql-test/t/subselect4.test:
Add test case.
sql/sql_select.cc:
If the (virtual) member function clone_item() returns NULL,
there is no substitution to be made, and we don't need to set the collation.
The test was invoking Item_cache::clone_item()
use limit efficiently
Bug #36569: UPDATE ... WHERE ... ORDER BY... always does a
filesort even if not required
Also two bugs reported after QA review (before the commit
of bugs above to public trees, no documentation needed):
Bug #53737: Performance regressions after applying patch
for bug 36569
Bug #53742: UPDATEs have no effect after applying patch
for bug 36569
Execution of single-table UPDATE and DELETE statements did not use the
same optimizer as was used in the compilation of SELECT statements.
Instead, it had an optimizer of its own that did not take into account
that you can omit sorting by retrieving rows using an index.
Extra optimization has been added: when applicable, single-table
UPDATE/DELETE statements use an existing index instead of filesort. A
corresponding SELECT query would do the former.
Also handling of the DESC ordering expression has been added when
reverse index scan is applicable.
From now on most single table UPDATE and DELETE statements show the
same disk access patterns as the corresponding SELECT query. We verify
this by comparing the result of SHOW STATUS LIKE 'Sort%
Currently the get_index_for_order function
a) checks quick select index (if any) for compatibility with the
ORDER expression list or
b) chooses the cheapest available compatible index, but only if
the index scan is cheaper than filesort.
Second way is implemented by the new test_if_cheaper_ordering
function (extracted part the test_if_skip_sort_order()).
mysql-test/r/log_state.result:
Updated result for optimized query, bug #36569.
mysql-test/r/single_delete_update.result:
Test case for bug #30584, bug #36569 and bug #53742.
mysql-test/r/update.result:
Updated result for optimized query, bug #30584.
Note:
"Handler_read_last 1" omitted, see bug 52312:
lost Handler_read_last status variable.
mysql-test/t/single_delete_update.test:
Test case for bug #30584, bug #36569 and bug #53742.
sql/opt_range.cc:
Bug #30584, bug #36569: UPDATE/DELETE ... WHERE ... ORDER BY...
always does a filesort even if not required
* get_index_for_order() has been rewritten entirely and moved
to sql_select.cc
New QUICK_RANGE_SELECT::make_reverse method has been added.
sql/opt_range.h:
Bug #30584, bug #36569: UPDATE/DELETE ... WHERE ... ORDER BY...
always does a filesort even if not required
* get_index_for_order() has been rewritten entirely and moved
to sql_select.cc
New functions:
* QUICK_SELECT_I::make_reverse()
* SQL_SELECT::set_quick()
sql/records.cc:
Bug #30584, bug #36569: UPDATE/DELETE ... WHERE ... ORDER BY...
always does a filesort even if not required
* init_read_record_idx() has been modified to allow reverse index scan
New functions:
* rr_index_last()
* rr_index_desc()
sql/records.h:
Bug #30584, bug #36569: UPDATE/DELETE ... WHERE ... ORDER BY...
always does a filesort even if not required
init_read_record_idx() has been modified to allow reverse index scan
sql/sql_delete.cc:
Bug #30584, bug #36569: UPDATE/DELETE ... WHERE ... ORDER BY...
always does a filesort even if not required
mysql_delete: an optimization has been added to skip
unnecessary sorting with ORDER BY clause where select
result ordering is acceptable.
sql/sql_select.cc:
Bug #30584, bug #36569, bug #53737, bug #53742:
UPDATE/DELETE ... WHERE ... ORDER BY... always does a filesort
even if not required
The const_expression_in_where function has been modified
to accept both Item and Field pointers.
New functions:
* get_index_for_order()
* test_if_cheaper_ordering() has been extracted from
test_if_skip_sort_order() to share with get_index_for_order()
* simple_remove_const()
sql/sql_select.h:
Bug #30584, bug #36569: UPDATE/DELETE ... WHERE ... ORDER BY...
always does a filesort even if not required
New functions:
* test_if_cheaper_ordering()
* simple_remove_const()
* get_index_for_order()
sql/sql_update.cc:
Bug #30584, bug #36569: UPDATE/DELETE ... WHERE ... ORDER BY...
always does a filesort even if not required
mysql_update: an optimization has been added to skip
unnecessary sorting with ORDER BY clause where a select
result ordering is acceptable.
sql/table.cc:
Bug #30584, bug #36569: UPDATE/DELETE ... WHERE ... ORDER BY...
always does a filesort even if not required
New functions:
* TABLE::update_const_key_parts()
* is_simple_order()
sql/table.h:
Bug #30584, bug #36569: UPDATE/DELETE ... WHERE ... ORDER BY...
always does a filesort even if not required
New functions:
* TABLE::update_const_key_parts()
* is_simple_order()
strict aliasing violations.
One somewhat major source of strict-aliasing violations and
related warnings is the SQL_LIST structure. For example,
consider its member function `link_in_list` which takes
a pointer to pointer of type T (any type) as a pointer to
pointer to unsigned char. Dereferencing this pointer, which
is done to reset the next field, violates strict-aliasing
rules and might cause problems for surrounding code that
uses the next field of the object being added to the list.
The solution is to use templates to parametrize the SQL_LIST
structure in order to deference the pointers with compatible
types. As a side bonus, it becomes possible to remove quite
a few casts related to acessing data members of SQL_LIST.
sql/handler.h:
Use the appropriate template type argument.
sql/item.cc:
Remove now-unnecessary cast.
sql/item_subselect.cc:
Remove now-unnecessary casts.
sql/item_sum.cc:
Use the appropriate template type argument.
Remove now-unnecessary cast.
sql/mysql_priv.h:
Move SQL_LIST structure to sql_list.h
Use the appropriate template type argument.
sql/sp.cc:
Remove now-unnecessary casts.
sql/sql_delete.cc:
Use the appropriate template type argument.
Remove now-unnecessary casts.
sql/sql_derived.cc:
Remove now-unnecessary casts.
sql/sql_lex.cc:
Remove now-unnecessary casts.
sql/sql_lex.h:
SQL_LIST now takes a template type argument which must
match the type of the elements of the list. Use forward
declaration when the type is not available, it is used
in pointers anyway.
sql/sql_list.h:
Rename SQL_LIST to SQL_I_List. The template parameter is
the type of object that is stored in the list.
sql/sql_olap.cc:
Remove now-unnecessary casts.
sql/sql_parse.cc:
Remove now-unnecessary casts.
sql/sql_prepare.cc:
Remove now-unnecessary casts.
sql/sql_select.cc:
Remove now-unnecessary casts.
sql/sql_show.cc:
Remove now-unnecessary casts.
sql/sql_table.cc:
Remove now-unnecessary casts.
sql/sql_trigger.cc:
Remove now-unnecessary casts.
sql/sql_union.cc:
Remove now-unnecessary casts.
sql/sql_update.cc:
Remove now-unnecessary casts.
sql/sql_view.cc:
Remove now-unnecessary casts.
sql/sql_yacc.yy:
Remove now-unnecessary casts.
storage/myisammrg/ha_myisammrg.cc:
Remove now-unnecessary casts.
Fix various mismatches between function's language linkage. Any
particular function that is declared in C++ but should be callable
from C must have C linkage. Note that function types with different
linkages are also distinct. Thus, if a function type is declared in
C code, it will have C linkage (same if declared in a extern "C"
block).
client/mysql.cc:
Mismatch between prototype and declaration.
client/mysqltest.cc:
mysqltest used to be C code. Use C linkage where appropriate.
cmd-line-utils/readline/input.c:
Isolate unreachable code.
include/my_alloc.h:
Function type must have C linkage.
include/my_base.h:
Function type must have C linkage.
include/my_global.h:
Add helper macros to avoid spurious namespace indentation.
include/mysql.h.pp:
Update ABI file.
mysys/my_gethwaddr.c:
Remove stray carriage return and fix coding style.
plugin/semisync/semisync_master_plugin.cc:
Callback function types have C linkage.
plugin/semisync/semisync_slave_plugin.cc:
Callback function types have C linkage.
sql/derror.cc:
Expected function type has C linkage.
sql/field.cc:
Use helper macro and fix indentation.
sql/handler.cc:
Expected function type has C linkage.
sql/item_sum.cc:
Correct function linkages. Remove now unnecessary cast.
sql/item_sum.h:
Add prototypes with the appropriate linkage as otherwise they
are distinct.
sql/mysqld.cc:
Wrap functions in C linkage mode.
sql/opt_range.cc:
C language linkage is ignored for class member functions.
sql/partition_info.cc:
Add wrapper functions with C linkage for class member functions.
sql/rpl_utility.h:
Use helper macro and fix indentation.
sql/sql_class.cc:
Change type of thd argument -- THD is a class.
Use helper macro and fix indentation.
sql/sql_class.h:
Change type of thd argument -- THD is a class.
sql/sql_select.cc:
Expected function type has C linkage.
sql/sql_select.h:
Move prototype to sql_test.h
sql/sql_show.cc:
Expected function type has C linkage.
sql/sql_test.cc:
Fix required function prototype and fix coding style.
sql/sql_test.h:
Removed unnecessary export and add another.
storage/myisammrg/ha_myisammrg.cc:
Expected function type has C linkage.
storage/perfschema/pfs.cc:
PSI headers are declared with C language linkage, which also
applies to function types.
There are two problems:
1. In simplify_joins function we calculate table dependencies. If STRAIGHT_JOIN hint
is used for whole SELECT we do not count it and as result some dependendecies
might be lost. It leads to incorrect table order which is returned by
join_tab_cmp_straight() function.
2. make_join_statistics() calculate the transitive closure for relations a particular
JOIN_TAB is 'dependent on'.
We aggregate the dependent table_map of a JOIN_TAB by adding dependencies from other
tables which we depend on. However, this may also cause new dependencies to be
available after we have completed processing a certain JOIN_TAB.
Both these problems affect condition pushdown and as result condition might be pushed
into wrong table which leads to crash or even omitted which leads to wrong result.
The fix:
1. Use modified 'transitive closure' algorithm provided by Ole John Aske
2. Update table dependences in simplify_joins according to
global STRAIGHT_JOIN hint.
Note: the patch also fixes bugs 46091 & 51492
mysql-test/r/join_outer.result:
test case
mysql-test/t/join_outer.test:
test case
sql/sql_select.cc:
1. Use modified 'transitive closure' algorithm provided by Ole John Aske
2. Update table dependences in simplify_joins according to
global STRAIGHT_JOIN hint.
Conflicts:
Text conflict in mysql-test/r/grant.result
Text conflict in mysql-test/t/grant.test
Text conflict in mysys/mf_loadpath.c
Text conflict in sql/slave.cc
Text conflict in sql/sql_priv.h
Conflicts:
Text conflict in mysql-test/r/explain.result
Text conflict in mysql-test/t/explain.test
Text conflict in sql/net_serv.cc
Text conflict in sql/sp_head.cc
Text conflict in sql/sql_priv.h
The fix actually reverts the change introduced
by the patch for bug 51494.
The fact is that patches for bugs 52177&48419
fix bugs 51194&50575 as well.
mysql-test/r/innodb_mysql.result:
test case
mysql-test/t/innodb_mysql.test:
test case
sql/sql_select.cc:
reverted wrong fix for bug 51494
greedy_search optimizer_search_depth=0
The algorithm inside restore_prev_nj_state failed to
properly update the counters within the NESTED_JOIN
tree. The counter was decremented each time a table in the
node was removed from the QEP, the correct thing to do being
only to decrement it when the last table in the child node
was removed from the plan. This lead to node counters
getting negative values and the plan thus appeared
impossible. An assertion caught this.
Fixed by not recursing up the tree unless the last table in
the join nest node is removed from the plan
WHERE predicates containing references to empty tables in a
subquery were handled incorrectly by the optimizer when
executing EXPLAIN. As a result, the optimizer could try to
evaluate such predicates rather than just stop with
"Impossible WHERE noticed after reading const tables" as
it would do in a non-subquery case. This led to valgrind
errors and crashes.
Fixed the code checking the above condition so that subqueries
are not excluded and hence are handled in the same way as top
level SELECTs.
mysql-test/r/explain.result:
Added a test case for bug #48419.
mysql-test/r/ps.result:
Updated test results to take the new (and more correct)
"Extra" comments in execution plans.
mysql-test/t/explain.test:
Added a test case for bug #48419.
sql/sql_select.cc:
There is no point in excluding subqueries from checking
for identically false WHERE conditions.
Fix for bug #46947 "Embedded SELECT without FOR UPDATE is
causing a lock", with after-review fixes.
SELECT statements with subqueries referencing InnoDB tables
were acquiring shared locks on rows in these tables when they
were executed in REPEATABLE-READ mode and with statement or
mixed mode binary logging turned on.
This was a regression which were introduced when fixing
bug 39843.
The problem was that for tables belonging to subqueries
parser set TL_READ_DEFAULT as a lock type. In cases when
statement/mixed binary logging at open_tables() time this
type of lock was converted to TL_READ_NO_INSERT lock at
open_tables() time and caused InnoDB engine to acquire
shared locks on reads from these tables. Although in some
cases such behavior was correct (e.g. for subqueries in
DELETE) in case of SELECT it has caused unnecessary locking.
This patch tries to solve this problem by rethinking our
approach to how we handle locking for SELECT and subqueries.
Now we always set TL_READ_DEFAULT lock type for all cases
when we read data. When at open_tables() time this lock
is interpreted as TL_READ_NO_INSERT or TL_READ depending
on whether this statement as a whole or call to function
which uses particular table should be written to the
binary log or not (if yes then statement should be properly
serialized with concurrent statements and stronger lock
should be acquired).
Test coverage is added for both InnoDB and MyISAM.
This patch introduces an "incompatible" change in locking
scheme for subqueries used in SELECT ... FOR UPDATE and
SELECT .. IN SHARE MODE.
In 4.1 the server would use a snapshot InnoDB read for
subqueries in SELECT FOR UPDATE and SELECT .. IN SHARE MODE
statements, regardless of whether the binary log is on or off.
If the user required a different type of read (i.e. locking read),
he/she could request so explicitly by providing FOR UPDATE/IN SHARE MODE
clause for each individual subquery.
On of the patches for 5.0 broke this behaviour (which was not documented
or tested), and started to use locking reads fora all subqueries in SELECT ...
FOR UPDATE/IN SHARE MODE. This patch restored 4.1 behaviour.
mysql-test/include/check_concurrent_insert.inc:
Added auxiliary script which allows to check if statement
reading table allows concurrent inserts in it.
mysql-test/include/check_no_concurrent_insert.inc:
Added auxiliary script which allows to check that statement
reading table doesn't allow concurrent inserts in it.
mysql-test/include/check_no_row_lock.inc:
Added auxiliary script which allows to check if statement
reading table doesn't take locks on its rows.
mysql-test/include/check_shared_row_lock.inc:
Added auxiliary script which allows to check if statement
reading table takes shared locks on some of its rows.
mysql-test/r/bug39022.result:
After bug #46947 'Embedded SELECT without FOR UPDATE is
causing a lock' was fixed test case for bug 39022 has to
be adjusted in order to trigger execution path on which
original problem was encountered.
mysql-test/r/innodb_mysql_lock2.result:
Added coverage for handling of locking in various cases when
we read data from InnoDB tables (includes test case for
bug #46947 'Embedded SELECT without FOR UPDATE is causing a
lock').
mysql-test/r/lock_sync.result:
Added coverage for handling of locking in various cases when
we read data from MyISAM tables.
mysql-test/t/bug39022.test:
After bug #46947 'Embedded SELECT without FOR UPDATE is
causing a lock' was fixed test case for bug 39022 has to
be adjusted in order to trigger execution path on which
original problem was encountered.
mysql-test/t/innodb_mysql_lock2.test:
Added coverage for handling of locking in various cases when
we read data from InnoDB tables (includes test case for
bug #46947 'Embedded SELECT without FOR UPDATE is causing a
lock').
mysql-test/t/lock_sync.test:
Added coverage for handling of locking in various cases when
we read data from MyISAM tables.
sql/log_event.cc:
Since LEX::lock_option member was removed we no longer can
rely on its value in Load_log_event::print_query() to
determine that log event correponds to LOAD DATA CONCURRENT
statement (this was not correct in all situations anyway).
A new Load_log_event's member was introduced as a replacement.
It is initialized at event object construction time and
explicitly indicates whether LOAD DATA was concurrent.
sql/log_event.h:
Since LEX::lock_option member was removed we no longer can
rely on its value in Load_log_event::print_query() to
determine that log event correponds to LOAD DATA CONCURRENT
statement (this was not correct in all situations anyway).
A new Load_log_event's member was introduced as a replacement.
It is initialized at event object construction time and
explicitly indicates whether LOAD DATA was concurrent.
sql/sp_head.cc:
sp_head::reset_lex():
Before parsing substatement reset part of parser state
which needs this (e.g. set Yacc_state::m_lock_type to
default value).
sql/sql_acl.cc:
Since LEX::reset_n_backup_query_tables_list() now also
resets LEX::sql_command member (as it became part of
Query_tables_list class) we have to restore it in cases
when while working with proxy Query_table_list we assume
that LEX::sql_command still corresponds to original SQL
command being executed (for example, when we are logging
statement to the binary log while having Query_tables_list
reset and backed up).
sql/sql_base.cc:
Changed read_lock_type_for_table() to return a weak TL_READ
type of lock in cases when we are executing statement which
won't update tables directly and table doesn't belong to
statement's prelocking list and thus can't be used by a
stored function. It is OK to do so since in this case table
won't be used by statement or function call which will be
written to the binary log, so serializability requirements
for it can be relaxed.
One of results from this change is that SELECTs on InnoDB
tables no longer takes shared row locks for tables which
are used in subqueries (i.e. bug #46947 is fixed).
Another result is that for similar SELECTs on MyISAM tables
concurrent inserts are allowed.
In order to implement this change signature of
read_lock_type_for_table() function was changed to take
pointers to Query_tables_list and TABLE_LIST objects.
sql/sql_base.h:
- Function read_lock_type_for_table() now takes pointers
to Query_tables_list and TABLE_LIST elements as its
arguments since to correctly determine lock type it needs
to know what statement is being performed and whether table
element for which lock type to be determined belongs to
prelocking list.
sql/sql_lex.cc:
- Removed LEX::lock_option and st_select_lex::lock_option
members. Places in parser that were using them now use
Yacc_state::m_lock_type instead.
- To emphasize that LEX::sql_command member is used during
process of opening and locking of tables it was moved to
Query_tables_list class. It is now reset by
Query_tables_list::reset_query_tables_list() method.
sql/sql_lex.h:
- Removed st_select_lex::lock_option member as there is no
real need for per-SELECT lock type (HIGH_PRIORITY option
should apply to the whole statement. FOR UPDATE/LOCK IN
SHARE MODE clauses can be handled without this member).
The main effect which was achieved by introduction of this
member, i.e. using TL_READ_DEFAULT lock type for
subqueries, is now achieved by setting LEX::lock_option
(or rather its replacement - Yacc_state::m_lock_type) to
TL_READ_DEFAULT in almost all cases.
- To emphasize that LEX::sql_command member is used during
process of opening and locking of tables it was moved to
Query_tables_list class.
- Replaced LEX::lock_option with Yacc_state::m_lock_type
in order to emphasize that this value is relevant only
during parsing. Unlike for LEX::lock_option the default
value for Yacc_state::m_lock_type is TL_READ_DEFAULT.
Note that for cases when it is OK to take a "weak" read
lock (e.g. simple SELECT) this lock type will be converted
to TL_READ at open_tables() time. So this change won't
cause negative change in behavior for such statements.
OTOH this change ensures that, for example, for SELECTs
which are used in stored functions TL_READ_NO_INSERT lock
is taken when necessary and as result calls to such stored
functions can be written to the binary log with correct
serialization.
sql/sql_load.cc:
Load_log_event constructor now requires a parameter that
indicates whether LOAD DATA is concurrent.
sql/sql_parse.cc:
LEX::lock_option was replaced with Yacc_state::m_lock_type.
And instead of resetting the latter implicitly in
mysql_init_multi_delete() we do it explicitly in the
places in parser which call this function.
sql/sql_priv.h:
- To be able more easily distinguish high-priority SELECTs
in st_select_lex::print() method added flag for
HIGH_PRIORITY option.
sql/sql_select.cc:
Changed code not to rely on LEX::lock_option to determine
that it is high-priority SELECT. It was replaced with
Yacc_state::m_lock_type which is accessible only at
parse time. So instead of LEX::lock_option we now rely
on a newly introduced flag for st_select_lex::options -
SELECT_HIGH_PRIORITY.
sql/sql_show.cc:
Since LEX::reset_n_backup_query_tables_list() now also
resets LEX::sql_command member (as it became part of
Query_tables_list class) we have to restore it in cases
when while working with proxy Query_table_list we assume
that LEX::sql_command still corresponds to original SQL
command being executed.
sql/sql_table.cc:
Since LEX::reset_query_tables_list() now also resets
LEX::sql_command member (as it became part of
Query_tables_list class) we have to restore value of this
member when this method is called by mysql_admin_table(),
to make this code safe for re-execution.
sql/sql_trigger.cc:
Since LEX::reset_n_backup_query_tables_list() now also
resets LEX::sql_command member (as it became part of
Query_tables_list class) we have to restore it in cases
when while working with proxy Query_table_list we assume
that LEX::sql_command still corresponds to original SQL
command being executed (for example, when we are logging
statement to the binary log while having Query_tables_list
reset and backed up).
sql/sql_update.cc:
Function read_lock_type_for_table() now takes pointers
to Query_tables_list and TABLE_LIST elements as its
arguments since to correctly determine lock type it needs
to know what statement is being performed and whether table
element for which lock type to be determined belongs to
prelocking list.
sql/sql_yacc.yy:
- Removed st_select_lex::lock_option member as there is no
real need for per-SELECT lock type (HIGH_PRIORITY option
should apply to the whole statement. FOR UPDATE/LOCK IN
SHARE MODE clauses can be handled without this member).
The main effect which was achieved by introduction of this
member, i.e. using TL_READ_DEFAULT lock type for
subqueries, is now achieved by setting LEX::lock_option
(or rather its replacement - Yacc_state::m_lock_type) to
TL_READ_DEFAULT in almost all cases.
- Replaced LEX::lock_option with Yacc_state::m_lock_type
in order to emphasize that this value is relevant only
during parsing. Unlike for LEX::lock_option the default
value for Yacc_state::m_lock_type is TL_READ_DEFAULT.
Note that for cases when it is OK to take a "weak" read
lock (e.g. simple SELECT) this lock type will be converted
to TL_READ at open_tables() time. So this change won't
cause negative change in behavior for such statements.
OTOH this change ensures that, for example, for SELECTs
which are used in stored functions TL_READ_NO_INSERT lock
is taken when necessary and as result calls to such stored
functions can be written to the binary log with correct
serialization.
- To be able more easily distinguish high-priority SELECTs
in st_select_lex::print() method we now use new flag
in st_select_lex::options bit-field.
The problem was in an incorrect debug assertion. The expression
used in the failing assertion states that when finding
references matching ORDER BY expressions, there can be only one
reference to a single table. But that does not make any sense,
all test cases for this bug are valid examples with multiple
identical WHERE expressions referencing the same table which
are also present in the ORDER BY list.
Fixed by removing the failing assertion. We also have to take
care of the 'found' counter so that we count multiple
references only once. We rely on this fact later in
eq_ref_table().
mysql-test/r/join.result:
Added a test case for bug #50335.
mysql-test/t/join.test:
Added a test case for bug #50335.
sql/sql_select.cc:
Removing the assertion in eq_ref_table() as it does not make
any sense. We also have to take care of the 'found' counter so
that we count multiple references only once. We rely on this
fact later in eq_ref_table().
union...order by (select... where...)
The problem is mysql is trying to materialize and
cache the scalar sub-queries at JOIN::optimize
even for EXPLAIN where the number of columns is
totally different from what's expected.
Fixed by not executing the scalar subqueries
for EXPLAIN.
Problem: Segmentation fault in add_group_and_distinct_keys() when accessing
field of what is assumed to be an Item_field object.
Cause: In case of views, the item added to list by is_indexed_agg_distinct()
was not of type Item_field, but Item_ref.
Resolution: Add the real Item_field object, the one referred to by
Item_ref object, to the list, instead.
mysql-test/r/count_distinct.result:
Results for test case for Bug#51980.
mysql-test/t/count_distinct.test:
Test case for Bug#51980.
Table needs to contain at least two rows to avoid const table optimization.
sql/sql_select.cc:
Make sure it is the actual Item_field object that is pushed to the out_args
list of is_indexed_agg_distinct(), and not Item_ref objects.
The problem is that we can not use make_cond_for_table().
This function relies on used_tables() condition
which is not set properly for subqueries.
As result subquery is not filtered out.
The fix is to use remove_eq_conds() function instead
of make_cond_for_table() func. 'remove_eq_conds()'
algorithm relies on const_item() value and it allows
to handle subqueries in right way.
mysql-test/r/having.result:
test case
mysql-test/t/having.test:
test case
sql/sql_select.cc:
The fix is to use remove_eq_conds() function instead
of make_cond_for_table() function.
Conflicts:
Text conflict in mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result
Text conflict in sql/log.cc
Text conflict in sql/set_var.cc
Text conflict in sql/sql_class.cc
This patch:
- Moves all definitions from the mysql_priv.h file into
header files for the component where the variable is
defined
- Creates header files if the component lacks one
- Eliminates all include directives from mysql_priv.h
- Eliminates all circular include cycles
- Rename time.cc to sql_time.cc
- Rename mysql_priv.h to sql_priv.h
