There is an optimization of DISTINCT in JOIN::optimize()
which depends on THD::used_tables value. Each SELECT statement
inside SP resets used_tables value(see mysql_select()) and it
leads to wrong result. The fix is to replace THD::used_tables
with LEX::used_tables.
mysql-test/r/sp.result:
test case
mysql-test/t/sp.test:
test case
sql/sql_base.cc:
THD::used_tables is replaced with LEX::used_tables
sql/sql_class.cc:
THD::used_tables is replaced with LEX::used_tables
sql/sql_class.h:
THD::used_tables is replaced with LEX::used_tables
sql/sql_insert.cc:
THD::used_tables is replaced with LEX::used_tables
sql/sql_lex.cc:
THD::used_tables is replaced with LEX::used_tables
sql/sql_lex.h:
THD::used_tables is replaced with LEX::used_tables
sql/sql_prepare.cc:
THD::used_tables is replaced with LEX::used_tables
sql/sql_select.cc:
THD::used_tables is replaced with LEX::used_tables
We must allocate a larger ref_pointer_array. We failed to account for extra
items allocated here:
#0 find_order_in_list
uint el= all_fields.elements;
all_fields.push_front(order_item); /* Add new field to field list. */
ref_pointer_array[el]= order_item;
order->item= ref_pointer_array + el;
#1 setup_order
#2 setup_without_group
#3 JOIN::prepare
mysql-test/r/order_by.result:
New test case.
mysql-test/r/union.result:
New test case.
mysql-test/t/order_by.test:
New test case.
mysql-test/t/union.test:
New test case.
sql/sql_lex.cc:
find_order_in_list() may need some extra space, so multiply og_num by two.
sql/sql_union.cc:
For UNION, the 'n_sum_items' are accumulated in the "global_parameters" select_lex.
This number must be propagated to setup_ref_array()
When preparing a 'fake_select_lex' we need to use global_parameters->order_list
rather than fake_select_lex->order_list (see comments inside st_select_lex_unit::cleanup)
The query was re-written *after* we had tagged it with NON_AGG_FIELD_USED.
Remove the flag before continuing.
mysql-test/r/explain.result:
Update test case for Bug#48295.
mysql-test/r/subselect.result:
New test case.
mysql-test/t/explain.test:
Update test case for Bug#48295.
mysql-test/t/subselect.test:
New test case.
sql/item.cc:
Use accessor functions for non_agg_field_used/agg_func_used.
sql/item_subselect.cc:
Remove non_agg_field_used when we rewrite query '1 < some (...)' => '1 < max(...)'
sql/item_sum.cc:
Use accessor functions for non_agg_field_used/agg_func_used.
sql/mysql_priv.h:
Remove unused #defines.
sql/sql_lex.cc:
Initialize new member variables.
sql/sql_lex.h:
Replace full_group_by_flag with two boolean flags,
and itroduce accessors for manipulating them.
sql/sql_select.cc:
Use accessor functions for non_agg_field_used/agg_func_used.
Backport to 5.0.
/*![:version:] Query Code */, where [:version:] is a sequence of 5
digits representing the mysql server version(e.g /*!50200 ... */),
is a special comment that the query in it can be executed on those
servers whose versions are larger than the version appearing in the
comment. It leads to a security issue when slave's version is larger
than master's. A malicious user can improve his privileges on slaves.
Because slave SQL thread is running with SUPER privileges, so it can
execute queries that he/she does not have privileges on master.
This bug is fixed with the logic below:
- To replace '!' with ' ' in the magic comments which are not applied on
master. So they become common comments and will not be applied on slave.
- Example:
'INSERT INTO t1 VALUES (1) /*!10000, (2)*/ /*!99999 ,(3)*/
will be binlogged as
'INSERT INTO t1 VALUES (1) /*!10000, (2)*/ /* 99999 ,(3)*/
--Bug#52157 various crashes and assertions with multi-table update, stored function
--Bug#54475 improper error handling causes cascading crashing failures in innodb/ndb
--Bug#57703 create view cause Assertion failed: 0, file .\item_subselect.cc, line 846
--Bug#57352 valgrind warnings when creating view
--Recently discovered problem when a nested materialized derived table is used
before being populated and it leads to incorrect result
We have several modes when we should disable subquery evaluation.
The reasons for disabling are different. It could be
uselessness of the evaluation as in case of 'CREATE VIEW'
or 'PREPARE stmt', or we should disable subquery evaluation
if tables are not locked yet as it happens in bug#54475, or
too early evaluation of subqueries can lead to wrong result
as it happened in Bug#19077.
Main problem is that if subquery items are treated as const
they are evaluated in ::fix_fields(), ::fix_length_and_dec()
of the parental items as a lot of these methods have
Item::val_...() calls inside.
We have to make subqueries non-const to prevent unnecessary
subquery evaluation. At the moment we have different methods
for this. Here is a list of these modes:
1. PREPARE stmt;
We use UNCACHEABLE_PREPARE flag.
It is set during parsing in sql_parse.cc, mysql_new_select() for
each SELECT_LEX object and cleared at the end of PREPARE in
sql_prepare.cc, init_stmt_after_parse(). If this flag is set
subquery becomes non-const and evaluation does not happen.
2. CREATE|ALTER VIEW, SHOW CREATE VIEW, I_S tables which
process FRM files
We use LEX::view_prepare_mode field. We set it before
view preparation and check this flag in
::fix_fields(), ::fix_length_and_dec().
Some bugs are fixed using this approach,
some are not(Bug#57352, Bug#57703). The problem here is
that we have a lot of ::fix_fields(), ::fix_length_and_dec()
where we use Item::val_...() calls for const items.
3. Derived tables with subquery = wrong result(Bug19077)
The reason of this bug is too early subquery evaluation.
It was fixed by adding Item::with_subselect field
The check of this field in appropriate places prevents
const item evaluation if the item have subquery.
The fix for Bug19077 fixes only the problem with
convert_constant_item() function and does not cover
other places(::fix_fields(), ::fix_length_and_dec() again)
where subqueries could be evaluated.
Example:
CREATE TABLE t1 (i INT, j BIGINT);
INSERT INTO t1 VALUES (1, 2), (2, 2), (3, 2);
SELECT * FROM (SELECT MIN(i) FROM t1
WHERE j = SUBSTRING('12', (SELECT * FROM (SELECT MIN(j) FROM t1) t2))) t3;
DROP TABLE t1;
4. Derived tables with subquery where subquery
is evaluated before table locking(Bug#54475, Bug#52157)
Suggested solution is following:
-Introduce new field LEX::context_analysis_only with the following
possible flags:
#define CONTEXT_ANALYSIS_ONLY_PREPARE 1
#define CONTEXT_ANALYSIS_ONLY_VIEW 2
#define CONTEXT_ANALYSIS_ONLY_DERIVED 4
-Set/clean these flags when we perform
context analysis operation
-Item_subselect::const_item() returns
result depending on LEX::context_analysis_only.
If context_analysis_only is set then we return
FALSE that means that subquery is non-const.
As all subquery types are wrapped by Item_subselect
it allow as to make subquery non-const when
it's necessary.
mysql-test/r/derived.result:
test case
mysql-test/r/multi_update.result:
test case
mysql-test/r/view.result:
test case
mysql-test/suite/innodb/r/innodb_multi_update.result:
test case
mysql-test/suite/innodb/t/innodb_multi_update.test:
test case
mysql-test/suite/innodb_plugin/r/innodb_multi_update.result:
test case
mysql-test/suite/innodb_plugin/t/innodb_multi_update.test:
test case
mysql-test/t/derived.test:
test case
mysql-test/t/multi_update.test:
test case
mysql-test/t/view.test:
test case
sql/item.cc:
--removed unnecessary code
sql/item_cmpfunc.cc:
--removed unnecessary checks
--THD::is_context_analysis_only() is replaced with LEX::is_ps_or_view_context_analysis()
sql/item_func.cc:
--refactored context analysis checks
sql/item_row.cc:
--removed unnecessary checks
sql/item_subselect.cc:
--removed unnecessary code
--added DBUG_ASSERT into Item_subselect::exec()
which asserts that subquery execution can not happen
if LEX::context_analysis_only is set, i.e. at context
analysis stage.
--Item_subselect::const_item()
Return FALSE if LEX::context_analysis_only is set.
It prevents subquery evaluation in ::fix_fields &
::fix_length_and_dec at context analysis stage.
sql/item_subselect.h:
--removed unnecessary code
sql/mysql_priv.h:
--Added new set of flags.
sql/sql_class.h:
--removed unnecessary code
sql/sql_derived.cc:
--added LEX::context_analysis_only analysis intialization/cleanup
sql/sql_lex.cc:
--init LEX::context_analysis_only field
sql/sql_lex.h:
--New LEX::context_analysis_only field
sql/sql_parse.cc:
--removed unnecessary code
sql/sql_prepare.cc:
--removed unnecessary code
--added LEX::context_analysis_only analysis intialization/cleanup
sql/sql_select.cc:
--refactored context analysis checks
sql/sql_show.cc:
--added LEX::context_analysis_only analysis intialization/cleanup
sql/sql_view.cc:
--added LEX::context_analysis_only analysis intialization/cleanup
Fix compiler warnings.
mysys/stacktrace.c:
Tag unused parameters.
sql/sql_lex.cc:
Variable becomes unused in non-debug builds. Also, no need to
assert the obvious.
/*![:version:] Query Code */, where [:version:] is a sequence of 5
digits representing the mysql server version(e.g /*!50200 ... */),
is a special comment that the query in it can be executed on those
servers whose versions are larger than the version appearing in the
comment. It leads to a security issue when slave's version is larger
than master's. A malicious user can improve his privileges on slaves.
Because slave SQL thread is running with SUPER privileges, so it can
execute queries that he/she does not have privileges on master.
This bug is fixed with the logic below:
- To replace '!' with ' ' in the magic comments which are not applied on
master. So they become common comments and will not be applied on slave.
- Example:
'INSERT INTO t1 VALUES (1) /*!10000, (2)*/ /*!99999 ,(3)*/
will be binlogged as
'INSERT INTO t1 VALUES (1) /*!10000, (2)*/ /* 99999 ,(3)*/
mysql-test/suite/rpl/t/rpl_conditional_comments.test:
Test the patch for this bug.
sql/mysql_priv.h:
Rename inBuf as rawBuf and remove the const limitation.
sql/sql_lex.cc:
To replace '!' with ' ' in the magic comments which are not applied on
master.
sql/sql_lex.h:
Remove the const limitation on parameter buff, as it can be modified in the function since
this patch.
Add member function yyUnput for Lex_input_stream. It set a character back the query buff.
sql/sql_parse.cc:
Rename inBuf as rawBuf and remove the const limitation.
sql/sql_partition.cc:
Remove the const limitation on parameter part_buff, as it can be modified in the function since
this patch.
sql/sql_partition.h:
Remove the const limitation on parameter part_buff, as it can be modified in the function since
this patch.
sql/table.h:
Remove the const limitation on variable partition_info, as it can be modified since
this patch.
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.
Item_hex_string::Item_hex_string
The status of memory allocation in the Lex_input_stream (called
from the Parser_state constructor) was not checked which led to
a parser crash in case of the out-of-memory error.
The solution is to introduce new init() member function in
Parser_state and Lex_input_stream so that status of memory
allocation can be returned to the caller.
mysql-test/r/error_simulation.result:
Added a test case for bug #42064.
mysql-test/t/error_simulation.test:
Added a test case for bug #42064.
mysys/my_alloc.c:
Added error injection code for the regression test.
mysys/my_malloc.c:
Added error injection code for the regression test.
mysys/safemalloc.c:
Added error injection code for the regression test.
sql/event_data_objects.cc:
Use the new init() member function of Parser_state and check
its return value to handle memory allocation failures.
sql/mysqld.cc:
Added error injection code for the regression test.
sql/sp.cc:
Use the new init() member function of Parser_state and check
its return value to handle memory allocation failures.
sql/sql_lex.cc:
Moved memory allocation from constructor to the separate init()
member function.
Added error injection code for the regression test.
sql/sql_lex.h:
Moved memory allocation from constructor to the separate init()
member function.
sql/sql_parse.cc:
Use the new init() member function of Parser_state and check
its return value to handle memory allocation failures.
sql/sql_partition.cc:
Use the new init() member function of Parser_state and check
its return value to handle memory allocation failures.
sql/sql_prepare.cc:
Use the new init() member function of Parser_state and check
its return value to handle memory allocation failures.
sql/sql_trigger.cc:
Use the new init() member function of Parser_state and check
its return value to handle memory allocation failures.
sql/sql_view.cc:
Use the new init() member function of Parser_state and check
its return value to handle memory allocation failures..
sql/thr_malloc.cc:
Added error injection code for the regression test.
The problem was that a syntactically invalid trigger could cause
the server to crash when trying to list triggers. The crash would
happen due to a mishap in the backup/restore procedure that should
protect parser items which are not associated with the trigger. The
backup/restore is used to isolate the parse tree (and context) of
a statement from the load (and parsing) of a trigger. In this case,
a error during the parsing of a trigger could cause the improper
backup/restore sequence.
The solution is to properly restore the original statement context
before the parser is exited due to syntax errors in the trigger body.
mysql-test/r/trigger.result:
Add test case result for Bug#50755
mysql-test/t/trigger.test:
Add test case for Bug#50755
sql/sp_head.cc:
Merge sp_head::destroy() and sp_head destructor. Retrieve THD
from the LEX so that m_thd is not necessary.
sql/sql_lex.cc:
Explicitly restore the original environment.
Grouping by a subquery in a query with a distinct aggregate
function lead to a wrong result (wrong and unordered
grouping values).
There are two related problems:
1) The query like this:
SELECT (SELECT t1.a) aa, COUNT(DISTINCT b) c
FROM t1 GROUP BY aa
returned wrong result, because the outer reference "t1.a"
in the subquery was substituted with the Item_ref item.
The Item_ref item obtains data from the result_field object
that refreshes once after the end of each group. This data
is not applicable to filesort since filesort() doesn't care
about groups (and doesn't update result_field objects with
copy_fields() and so on). Also that data is not applicable
to group separation algorithm: end_send_group() checks every
record with test_if_group_changed() that evaluates Item_ref
items, but it refreshes those Item_ref-s only after the end
of group, that is a vicious circle and the grouped column
values in the output are shifted.
Fix: if
a) we grouping by a subquery and
b) that subquery has outer references to FROM list
of the grouping query,
then we substitute these outer references with
Item_direct_ref like references under aggregate
functions: Item_direct_ref obtains data directly
from the current record.
2) The query with a non-trivial grouping expression like:
SELECT (SELECT t1.a) aa, COUNT(DISTINCT b) c
FROM t1 GROUP BY aa+0
also returned wrong result, since JOIN::exec() substitutes
references to top-level aliases in SELECT list with Item_copy
caching items. Item_copy items have same refreshing policy
as Item_ref items, so the whole groping expression with
Item_copy inside returns wrong result in filesort() and
end_send_group().
Fix: include aliased items into GROUP BY item tree instead
of Item_ref references to them.
mysql-test/r/group_by.result:
Test case for bug #45640
mysql-test/t/group_by.test:
Test case for bug #45640
sql/item.cc:
Bug #45640: optimizer bug produces wrong results
Item_field::fix_fields() has been modified to resolve
aliases in GROUP BY item trees into aliased items instead
of Item_ref items.
sql/item.h:
Bug #45640: optimizer bug produces wrong results
- Item::find_item_processor() has been introduced.
- Item_ref::walk() has been modified to apply processors
to itself too (not only to referenced item).
sql/mysql_priv.h:
Bug #45640: optimizer bug produces wrong results
fix_inner_refs() has been modified to accept group_list
parameter.
sql/sql_lex.cc:
Bug #45640: optimizer bug produces wrong results
Initialization of st_select_lex::group_fix_field has
been added.
sql/sql_lex.h:
Bug #45640: optimizer bug produces wrong results
The st_select_lex::group_fix_field field has been introduced
to control alias resolution in Itef_fied::fix_fields.
sql/sql_select.cc:
Bug #45640: optimizer bug produces wrong results
- The fix_inner_refs function has been modified to treat
subquery outer references like outer fields under aggregate
functions, if they are included in GROUP BY item tree.
- The find_order_in_list function has been modified to
fix Item_field alias fields included in the GROUP BY item
trees in a special manner.
The problem is that the lexer could inadvertently skip over the
end of a query being parsed if it encountered a malformed multibyte
character. A specially crated query string could cause the lexer
to jump up to six bytes past the end of the query buffer. Another
problem was that the laxer could use unfiltered user input as
a signed array index for the parser maps (having upper and lower
bounds 0 and 256 respectively).
The solution is to ensure that the lexer only skips over well-formed
multibyte characters and that the index value of the parser maps
is always a unsigned value.
mysql-test/r/ctype_recoding.result:
Update test case result: ending backtick is not skipped over anymore.
sql/sql_lex.cc:
Characters being analyzed must be unsigned as they can be
used as indexes for the parser maps. Only skip over if the
string is a valid multi-byte sequence.
tests/mysql_client_test.c:
Add test case for Bug#45010
with gcc 4.3.2
Compiling MySQL with gcc 4.3.2 and later produces a number of
warnings, many of which are new with the recent compiler
versions.
This bug will be resolved in more than one patch to limit the
size of changesets. This is the second patch, fixing more
of the warnings.
with gcc 4.3.2
Compiling MySQL with gcc 4.3.2 and later produces a number of
warnings, many of which are new with the recent compiler
versions.
This bug will be resolved in more than one patch to limit the
size of changesets. This is the second patch, fixing more
of the warnings.
Added a more detailed error message on calling an ambiguous missing function.
mysql-test/r/ps.result:
Bug #38159: fixed existing tests
mysql-test/r/sp-error.result:
Bug #38159: test case
mysql-test/t/ps.test:
Bug #38159: fixed existing tests
mysql-test/t/sp-error.test:
Bug #38159: test case
sql/item_func.cc:
Bug #38159: generate more detailed error message
sql/share/errmsg.txt:
Bug #38159: add a more detailed error message
sql/sql_derived.cc:
Bug #38159: treat the detailed error message the same way as the
generic one
sql/sql_lex.cc:
Bug #38159:
- detect if the token is ambiguous and print the appropriate error.
- backport is_lex_native_function() from 5.1
sql/sql_lex.h:
Bug #38159: detect if the token is ambiguous and print the appropriate error.
sql/sql_yacc.yy:
Bug #38159: generate more detailed error message
sql/table.cc:
Bug #38159: treat the detailed error message the same way as the
generic one
comment can't be read back
A change to the lexer in 5.1 caused slash-asterisk-bang-version
sections to be terminated early if there exists a slash-asterisk-
style comment inside it. Nesting comments is usually illegal,
but we rely on versioned comment blocks in mysqldump, and the
contents of those sections must be allowed to have comments.
The problem was that when encountering open-comment tokens and
consuming -or- passing through the contents, the "in_comment"
state at the end was clobbered with the not-in-a-comment value,
regardless of whether we were in a comment before this or not.
So, """/*!VER one /* two */ three */""" would lose its in-comment
state between "two" and "three". Save the echo and in-comment
state, and restore it at the end of the comment if we consume a
comment.
The problem is that a SELECT .. FOR UPDATE statement might open
a table and later wait for a impeding global read lock without
noticing whether it is holding a table that is being waited upon
the the flush phase of the process that took the global read
lock.
The same problem also affected the following statements:
LOCK TABLES .. WRITE
UPDATE .. SET (update and multi-table update)
TRUNCATE TABLE ..
LOAD DATA ..
The solution is to make the above statements wait for a impending
global read lock before opening the tables. If there is no
impending global read lock, the statement raises a temporary
protection against global read locks and progresses smoothly
towards completion.
Important notice: the patch does not try to address all possible
cases, only those which are common and can be fixed unintrusively
enough for 5.0.
mysql-test/r/lock_multi.result:
Add test case result for Bug#43230
mysql-test/t/lock_multi.test:
Add test case for Bug#43230
sql/sql_lex.cc:
Initialize flag.
sql/sql_lex.h:
Add a flag to the lexer.
sql/sql_parse.cc:
Wait for the global read lock is a write lock is going to be
taken. The wait is done before opening tables.
sql/sql_yacc.yy:
Protect against the GRL if its a SELECT .. FOR UPDATE or LOCK TABLES
.. WRITE statement.
An unnecessarily restrictive lock were taken on sub-SELECTs during DELETE.
During parsing, a global structure is reused for sub-SELECTs and the attribute
keeping track of lock options were not reset properly.
This patch introduces a new attribute to keep track on the syntactical lock
option elements found in a sub-SELECT and then sets the lock options accordingly.
Now the sub-SELECTs will try to acquire a READ lock if possible
instead of a WRITE lock as inherited from the outer DELETE statement.
mysql-test/r/lock.result:
Added test case for bug39843
mysql-test/t/lock.test:
Added test case for bug39843
sql/sql_lex.cc:
* Reset member variable lock_option on each new query.
sql/sql_lex.h:
* Introduced new member variable 'lock_option' which is keeping track
of the syntactical lock option of a (sub-)select query.
sql/sql_parse.cc:
* Wrote comments to functions.
sql/sql_yacc.yy:
* Introduced an attribute to keep track of syntactical lock options
in sub-selects.
* Made sure that the default value TL_READ_DEFAULT is at the begining
of each subselect-rule.
- Remove bothersome warning messages. This change focuses on the warnings
that are covered by the ignore file: support-files/compiler_warnings.supp.
- Strings are guaranteed to be max uint in length
- Remove bothersome warning messages. This change focuses on the warnings
that are covered by the ignore file: support-files/compiler_warnings.supp.
- Strings are guaranteed to be max uint in length
Related to operator precedence and associativity.
Make the expressions as explicit as possible.
sql/field.h:
Silence gcc-4.3 warning: be more explicit.
sql/item.cc:
Silence gcc-4.3 warning: be more explicit.
sql/item_sum.cc:
Silence gcc-4.3 warning: be more explicit.
sql/log_event.cc:
Silence gcc-4.3 warning: be more explicit.
sql/spatial.h:
Silence gcc-4.3 warning: be more explicit.
sql/sql_lex.cc:
Silence gcc-4.3 warning: be more explicit.
sql/table.h:
Silence gcc-4.3 warning: be more explicit.
storage/federated/ha_federated.cc:
Fix operator precedence bug.
storage/heap/ha_heap.cc:
Silence gcc-4.3 warning: be more explicit.
The problem is that the offset argument of the limit clause
might be truncated on a 32-bits server built without big
tables support. The truncation was happening because the
original 64-bits long argument was being cast to a 32-bits
(ha_rows) offset counter.
The solution is to check if the conversing resulted in value
truncation and if so, the offset is set to the maximum possible
value that can fit on the type.
mysql-test/r/limit.result:
Add test case result for Bug#37075
mysql-test/t/limit.test:
Add test case for Bug#37075
sql/sql_lex.cc:
Check for truncation of the offset value. If value was
truncated, set to the maximum possible value.
``FLUSH TABLES WITH READ LOCK''
Concurrent execution of 1) multitable update with a
NATURAL/USING join and 2) a such query as "FLUSH TABLES
WITH READ LOCK" or "ALTER TABLE" of updating table led
to a server crash.
The mysql_multi_update_prepare() function call is optimized
to lock updating tables only, so it postpones locking to
the last, and if locking fails, it does cleanup of modified
syntax structures and repeats a query analysis. However,
that cleanup procedure was incomplete for NATURAL/USING join
syntax data: 1) some Field_item items pointed into freed
table structures, and 2) the TABLE_LIST::join_columns fields
was not reset.
Major change:
short-living Field *Natural_join_column::table_field has
been replaced with long-living Item*.
mysql-test/r/lock_multi.result:
Added test case for bug #38691.
mysql-test/t/lock_multi.test:
Added test case for bug #38691.
sql/item.cc:
Bug #38691: segfault/abort in ``UPDATE ...JOIN'' while
``FLUSH TABLES WITH READ LOCK''
The Item_field constructor has been modified to allocate
and copy original database/table/field names always (not
during PS preparation/1st execution only), because
an initialization of Item_field items with a pointer to
short-living Field structures is a common practice.
sql/sql_base.cc:
Bug #38691: segfault/abort in ``UPDATE ...JOIN'' while
``FLUSH TABLES WITH READ LOCK''
1) Type adjustment for Natural_join_column::table_field
(Field to Item_field);
2) The setup_natural_join_row_types function has been
updated to take into account new
first_natural_join_processing flag to skip unnecessary
reinitialization of Natural_join_column::join_columns
during table reopening after lock_tables() failure
(like the 'first_execution' flag for PS).
sql/sql_lex.cc:
Bug #38691: segfault/abort in ``UPDATE ...JOIN'' while
``FLUSH TABLES WITH READ LOCK''
Initialization of the new
st_select_lex::first_natural_join_processing flag has
been added.
sql/sql_lex.h:
Bug #38691: segfault/abort in ``UPDATE ...JOIN'' while
``FLUSH TABLES WITH READ LOCK''
The st_select_lex::first_natural_join_processing flag
has been added to skip unnecessary rebuilding of
NATURAL/USING JOIN structures during table reopening
after lock_tables failure.
sql/sql_update.cc:
Bug #38691: segfault/abort in ``UPDATE ...JOIN'' while
``FLUSH TABLES WITH READ LOCK''
Extra cleanup calls have been added to reset
Natural_join_column::table_field items.
sql/table.cc:
Bug #38691: segfault/abort in ``UPDATE ...JOIN'' while
``FLUSH TABLES WITH READ LOCK''
Type adjustment for Natural_join_column::table_field
(Field to Item_field).
sql/table.h:
Bug #38691: segfault/abort in ``UPDATE ...JOIN'' while
``FLUSH TABLES WITH READ LOCK''
Type of the Natural_join_column::table_field field has
been changed from Field that points into short-living
TABLE memory to long-living Item_field that can be
linked to (fixed) reopened table.
columns data types
The "SELECT @lastId, @lastId := Id FROM t" query returns
different result sets depending on the type of the Id column
(INT or BIGINT).
Note: this fix doesn't cover the case when a select query
references an user variable and stored function that
updates a value of that variable, in this case a result
is indeterminate.
The server uses incorrect assumption about a constantness of
an user variable value as a select list item:
The server caches a last query number where that variable
was changed and compares this number with a current query
number. If these numbers are different, the server guesses,
that the variable is not updating in the current query, so
a respective select list item is a constant. However, in some
common cases the server updates cached query number too late.
The server has been modified to memorize user variable
assignments during the parse phase to take them into account
on the next (query preparation) phase independently of the
order of user variable references/assignments in a select
item list.
mysql-test/r/user_var.result:
Added test case for bug #26020.
mysql-test/t/user_var.test:
Added test case for bug #26020.
sql/item_func.cc:
An update of entry and update_query_id variables has been
moved from Item_func_set_user_var::fix_fields() to a separate
method, Item_func_set_user_var::set_entry().
sql/item_func.h:
1. The Item_func_set_user_var::set_entry() method has been
added to update Item_func_set_user_var::entry.
2. The Item_func_set_user_var::entry_thd field has beend
added to update Item_func_set_user_var::entry only when
needed.
sql/sql_base.cc:
Fix: setup_fiedls() calls Item_func_set_user_var::set_entry()
for all items from the thd->lex->set_var_list before the first
call of ::fix_fields().
sql/sql_lex.cc:
The lex_start function has been modified to reset
the st_lex::set_var_list list.
sql/sql_lex.h:
New st_lex::set_var_list field has been added to
memorize all user variable assignments in the current
select query.
sql/sql_yacc.yy:
The variable_aux rule has been modified to memorize
in-query user variable assignments in the
st_lex::set_var_list list.
build)
The crash was caused by freeing the internal parser stack during the parser
execution.
This occured only for complex stored procedures, after reallocating the parser
stack using my_yyoverflow(), with the following C call stack:
- MYSQLparse()
- any rule calling sp_head::restore_lex()
- lex_end()
- x_free(lex->yacc_yyss), xfree(lex->yacc_yyvs)
The root cause is the implementation of stored procedures, which breaks the
assumption from 4.1 that there is only one LEX structure per parser call.
The solution is to separate the LEX structure into:
- attributes that represent a statement (the current LEX structure),
- attributes that relate to the syntax parser itself (Yacc_state),
so that parsing multiple statements in stored programs can create multiple
LEX structures while not changing the unique Yacc_state.
Now, Yacc_state and the existing Lex_input_stream are aggregated into
Parser_state, a structure that represent the complete state of the (Lexical +
Syntax) parser.
mysql-test/r/parser_stack.result:
Bug#35577 (CREATE PROCEDURE causes either crash or syntax error depending on
build)
mysql-test/t/parser_stack.test:
Bug#35577 (CREATE PROCEDURE causes either crash or syntax error depending on
build)
sql/sp.cc:
Bug#35577 (CREATE PROCEDURE causes either crash or syntax error depending on
build)
sql/sp_head.cc:
Bug#35577 (CREATE PROCEDURE causes either crash or syntax error depending on
build)
sql/sql_class.cc:
Bug#35577 (CREATE PROCEDURE causes either crash or syntax error depending on
build)
sql/sql_class.h:
Bug#35577 (CREATE PROCEDURE causes either crash or syntax error depending on
build)
sql/sql_lex.cc:
Bug#35577 (CREATE PROCEDURE causes either crash or syntax error depending on
build)
sql/sql_lex.h:
Bug#35577 (CREATE PROCEDURE causes either crash or syntax error depending on
build)
sql/sql_parse.cc:
Bug#35577 (CREATE PROCEDURE causes either crash or syntax error depending on
build)
sql/sql_prepare.cc:
Bug#35577 (CREATE PROCEDURE causes either crash or syntax error depending on
build)
sql/sql_trigger.cc:
Bug#35577 (CREATE PROCEDURE causes either crash or syntax error depending on
build)
sql/sql_view.cc:
Bug#35577 (CREATE PROCEDURE causes either crash or syntax error depending on
build)
sql/sql_yacc.yy:
Bug#35577 (CREATE PROCEDURE causes either crash or syntax error depending on
build)
