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.
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.
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.
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.
- 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
Adding comments to some of the high-level functions in replication.
sql/log_event.h:
Fixed some mistakes in comments.
sql/repl_failsafe.cc:
Added comment for show_slave_hosts()
sql/slave.cc:
Added comment for show_master_info(), handle_slave_[sql|io](), and next_event()
sql/sql_binlog.cc:
Added @param comment.
sql/sql_lex.h:
Added comment for st_lex_master_info.
sql/sql_repl.cc:
Added comments for functions executing a statement:
PURGE BINARY LOGS
START SLAVE
STOP SLAVE
RESET SLAVE
CHANGE MASTER
RESET MASTER
SHOW BINLOG EVENTS
SHOW MASTER STATUS
SHOW BINARY LOGS
on non-partitioned table
Problem was that partitioning specific commands was accepted
for non partitioned tables and treated like
ANALYZE/CHECK/OPTIMIZE/REPAIR TABLE, after bug-20129 was fixed,
which changed the code path from mysql_alter_table to
mysql_admin_table.
Solution was to check if the table was partitioned before
trying to execute the admin command
mysql-test/r/partition_mgm_err.result:
Bug#39434: ALTER TABLE CHECK/OPTIMIZE/ANALYZE PARTITION work
on non-partitioned table
Updated test result
mysql-test/t/partition_mgm_err.test:
Bug#39434: ALTER TABLE CHECK/OPTIMIZE/ANALYZE PARTITION work
on non-partitioned table
Updated test case
sql/ha_partition.cc:
Bug#39434: ALTER TABLE CHECK/OPTIMIZE/ANALYZE PARTITION work
on non-partitioned table
Simplified the code by using ALTER_ADMIN_PARTITION for all
commands that go through mysql_admin_tables and is set
for partitioning specific commands that.
sql/ha_partition.h:
Bug#39434: ALTER TABLE CHECK/OPTIMIZE/ANALYZE PARTITION work
on non-partitioned table
Simplified the code by using ALTER_ADMIN_PARTITION for all
commands that go through mysql_admin_tables and is set
for partitioning specific commands that.
sql/sql_lex.h:
Bug#39434: ALTER TABLE CHECK/OPTIMIZE/ANALYZE PARTITION work
on non-partitioned table
Simplified the code by using ALTER_ADMIN_PARTITION for all
commands that go through mysql_admin_tables and is set
for partitioning specific commands that.
Removed ALTER_ANALYZE/CHECK/OPTIMIZE/REPAIR_PARTITION and
added ALTER_ADMIN_PARTITION instead.
sql/sql_partition.cc:
Bug#39434: ALTER TABLE CHECK/OPTIMIZE/ANALYZE PARTITION work
on non-partitioned table
Simplified the code by using ALTER_ADMIN_PARTITION for all
commands that go through mysql_admin_tables and is set
for partitioning specific commands that.
Removed ALTER_ANALYZE/CHECK/OPTIMIZE/REPAIR_PARTITION and
added ALTER_ADMIN_PARTITION instead.
sql/sql_table.cc:
Bug#39434: ALTER TABLE CHECK/OPTIMIZE/ANALYZE PARTITION work
on non-partitioned table
Give error and return if trying partitioning admin command
on non partitioned table.
Simplified the code by using ALTER_ADMIN_PARTITION for all
commands that go through mysql_admin_tables and is set
for partitioning specific commands that.
Removed ALTER_ANALYZE/CHECK/OPTIMIZE/REPAIR_PARTITION and
added ALTER_ADMIN_PARTITION instead.
sql/sql_yacc.yy:
Bug#39434: ALTER TABLE CHECK/OPTIMIZE/ANALYZE PARTITION work
on non-partitioned table
Simplified the code by using ALTER_ADMIN_PARTITION for all
commands that go through mysql_admin_tables and is set
for partitioning specific commands that.
Removed ALTER_ANALYZE/CHECK/OPTIMIZE/REPAIR_PARTITION and
added ALTER_ADMIN_PARTITION instead.
on non-partitioned table
Problem was that partitioning specific commands was accepted
for non partitioned tables and treated like
ANALYZE/CHECK/OPTIMIZE/REPAIR TABLE, after bug-20129 was fixed,
which changed the code path from mysql_alter_table to
mysql_admin_table.
Solution was to check if the table was partitioned before
trying to execute the admin command
``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.
``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*.
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.
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.
This fix is for 5.0 only : back porting the 6.0 patch manually
The parser code in sql/sql_yacc.yy needs to be more robust to out of
memory conditions, so that when parsing a query fails due to OOM,
the thread gracefully returns an error.
Before this fix, a new/alloc returning NULL could:
- cause a crash, if dereferencing the NULL pointer,
- produce a corrupted parsed tree, containing NULL nodes,
- alter the semantic of a query, by silently dropping token values or nodes
With this fix:
- C++ constructors are *not* executed with a NULL "this" pointer
when operator new fails.
This is achieved by declaring "operator new" with a "throw ()" clause,
so that a failed new gracefully returns NULL on OOM conditions.
- calls to new/alloc are tested for a NULL result,
- The thread diagnostic area is set to an error status when OOM occurs.
This ensures that a request failing in the server properly returns an
ER_OUT_OF_RESOURCES error to the client.
- OOM conditions cause the parser to stop immediately (MYSQL_YYABORT).
This prevents causing further crashes when using a partially built parsed
tree in further rules in the parser.
No test scripts are provided, since automating OOM failures is not
instrumented in the server.
Tested under the debugger, to verify that an error in alloc_root cause the
thread to returns gracefully all the way to the client application, with
an ER_OUT_OF_RESOURCES error.
This fix is for 5.0 only : back porting the 6.0 patch manually
The parser code in sql/sql_yacc.yy needs to be more robust to out of
memory conditions, so that when parsing a query fails due to OOM,
the thread gracefully returns an error.
Before this fix, a new/alloc returning NULL could:
- cause a crash, if dereferencing the NULL pointer,
- produce a corrupted parsed tree, containing NULL nodes,
- alter the semantic of a query, by silently dropping token values or nodes
With this fix:
- C++ constructors are *not* executed with a NULL "this" pointer
when operator new fails.
This is achieved by declaring "operator new" with a "throw ()" clause,
so that a failed new gracefully returns NULL on OOM conditions.
- calls to new/alloc are tested for a NULL result,
- The thread diagnostic area is set to an error status when OOM occurs.
This ensures that a request failing in the server properly returns an
ER_OUT_OF_RESOURCES error to the client.
- OOM conditions cause the parser to stop immediately (MYSQL_YYABORT).
This prevents causing further crashes when using a partially built parsed
tree in further rules in the parser.
No test scripts are provided, since automating OOM failures is not
instrumented in the server.
Tested under the debugger, to verify that an error in alloc_root cause the
thread to returns gracefully all the way to the client application, with
an ER_OUT_OF_RESOURCES error.
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)
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.
into moonbone.local:/work/27219-bug-5.1
sql/item_subselect.cc:
Auto merged
sql/item_sum.cc:
Auto merged
sql/item_sum.h:
Auto merged
sql/mysql_priv.h:
Auto merged
sql/sql_lex.cc:
Auto merged
sql/sql_select.cc:
Auto merged
mysql-test/r/group_by.result:
SCCS merged
mysql-test/t/group_by.test:
SCCS merged
sql/item.cc:
SCCS merged
sql/sql_lex.h:
SCCS merged
Mixing aggregate functions and non-grouping columns is not allowed in the
ONLY_FULL_GROUP_BY mode. However in some cases the error wasn't thrown because
of insufficient check.
In order to check more thoroughly the new algorithm employs a list of outer
fields used in a sum function and a SELECT_LEX::full_group_by_flag.
Each non-outer field checked to find out whether it's aggregated or not and
the current select is marked accordingly.
All outer fields that are used under an aggregate function are added to the
Item_sum::outer_fields list and later checked by the Item_sum::check_sum_func
function.
mysql-test/t/group_by.test:
Added a test case for the bug#27219: Aggregate functions in ORDER BY.
mysql-test/r/group_by.result:
Added a test case for the bug#27219: Aggregate functions in ORDER BY.
sql/sql_select.cc:
Bug#27219: Aggregate functions in ORDER BY.
Implementation of new check for mixing non aggregated fields and aggregation
function in the ONLY_FULL_GROUP_BY mode.
sql/sql_lex.cc:
Bug#27219: Aggregate functions in ORDER BY.
Initialization of the full_group_by_flag bitmap.
SELECT_LEX::test_limit function doesn't reset ORDER BY
clause anymore.
sql/sql_lex.h:
Bug#27219: Aggregate functions in ORDER BY.
The full_group_by_flag is added to the SELECT_LEX class.
sql/item_sum.h:
Bug#27219: Aggregate functions in ORDER BY.
The outer_fields list is added to the Item_sum class.
sql/mysql_priv.h:
Bug#27219: Aggregate functions in ORDER BY.
Defined a set of constants used in the new check for mixing non aggregated
fields and sum functions in the ONLY_FULL_GROUP_BY_MODE.
sql/item_subselect.cc:
Bug#27219: Aggregate functions in ORDER BY.
The Item_in_subselect::select_in_like_transformer function now drops
ORDER BY clause in all selects in a subquery.
sql/item_sum.cc:
Bug#27219: Aggregate functions in ORDER BY.
Now the Item_sum::check_sum_func function now checks whether fields in the
outer_fields list are aggregated or not and marks selects accordingly.
sql/item.cc:
Bug#27219: Aggregate functions in ORDER BY.
Now the Item_field::fix_fields function checks whether the field is aggregated
or not and marks its select_lex accordingly.
Mixing aggregate functions and non-grouping columns is not allowed in the
ONLY_FULL_GROUP_BY mode. However in some cases the error wasn't thrown because
of insufficient check.
In order to check more thoroughly the new algorithm employs a list of outer
fields used in a sum function and a SELECT_LEX::full_group_by_flag.
Each non-outer field checked to find out whether it's aggregated or not and
the current select is marked accordingly.
All outer fields that are used under an aggregate function are added to the
Item_sum::outer_fields list and later checked by the Item_sum::check_sum_func
function.
between 5.0 and 5.1.
The problem was that in the patch for Bug#11986 it was decided
to store original query in UTF8 encoding for the INFORMATION_SCHEMA.
This approach however turned out to be quite difficult to implement
properly. The main problem is to preserve the same IS-output after
dump/restore.
So, the fix is to rollback to the previous functionality, but also
to fix it to support multi-character-set-queries properly. The idea
is to generate INFORMATION_SCHEMA-query from the item-tree after
parsing view declaration. The IS-query should:
- be completely in UTF8;
- not contain character set introducers.
For more information, see WL4052.
mysql-test/include/ddl_i18n.check_views.inc:
Add a test case for Bug#30217.
mysql-test/r/ddl_i18n_koi8r.result:
Update result file.
mysql-test/r/ddl_i18n_utf8.result:
Update result file.
mysql-test/r/information_schema.result:
Update result file.
mysql-test/r/information_schema_db.result:
Update result file.
mysql-test/r/mysqldump.result:
Update result file.
mysql-test/r/show_check.result:
Update result file.
mysql-test/t/ddl_i18n_koi8r.test:
Add a test case for Bug#30217.
mysql-test/t/ddl_i18n_utf8.test:
Add a test case for Bug#30217.
mysql-test/t/mysqldump.test:
Add a test case for Bug#30217.
sql/ha_ndbcluster.cc:
Add a parameter to print().
sql/item.cc:
1. Add a parameter to print().
2. Item_string::print():
- Do not append character set introducer to the text literal
if we're building a query for INFORMATION_SCHEMA;
- Convert text literal to UTF8 if we're building a query
for INFORMATION_SCHEMA.
sql/item.h:
Add a parameter to print().
sql/item_cmpfunc.cc:
Add a parameter to print().
sql/item_cmpfunc.h:
Add a parameter to print().
sql/item_func.cc:
Add a parameter to print().
sql/item_func.h:
Add a parameter to print().
sql/item_geofunc.h:
Add a parameter to print().
sql/item_row.cc:
Add a parameter to print().
sql/item_row.h:
Add a parameter to print().
sql/item_strfunc.cc:
Add a parameter to print().
sql/item_strfunc.h:
Add a parameter to print().
sql/item_subselect.cc:
Add a parameter to print().
sql/item_subselect.h:
Add a parameter to print().
sql/item_sum.cc:
Add a parameter to print().
sql/item_sum.h:
Add a parameter to print().
sql/item_timefunc.cc:
Add a parameter to print().
sql/item_timefunc.h:
Add a parameter to print().
sql/mysql_priv.h:
Add a parameter to print().
sql/sp_head.cc:
Add a parameter to print().
sql/sql_lex.cc:
Add a parameter to print().
sql/sql_lex.h:
Add a parameter to print().
sql/sql_parse.cc:
Add a parameter to print().
sql/sql_select.cc:
Add a parameter to print().
sql/sql_show.cc:
Add a parameter to print().
sql/sql_test.cc:
Add a parameter to print().
sql/sql_view.cc:
Build INFORMATION_SCHEMA query from Item-tree.
sql/sql_yacc.yy:
Build INFORMATION_SCHEMA query from Item-tree.
sql/table.h:
Add a parameter to print().
between 5.0 and 5.1.
The problem was that in the patch for Bug#11986 it was decided
to store original query in UTF8 encoding for the INFORMATION_SCHEMA.
This approach however turned out to be quite difficult to implement
properly. The main problem is to preserve the same IS-output after
dump/restore.
So, the fix is to rollback to the previous functionality, but also
to fix it to support multi-character-set-queries properly. The idea
is to generate INFORMATION_SCHEMA-query from the item-tree after
parsing view declaration. The IS-query should:
- be completely in UTF8;
- not contain character set introducers.
For more information, see WL4052.
The problem is that when a stored procedure is being parsed for
the first execution, the body is copied to a temporary buffer
which is disregarded sometime after the statement is parsed.
And during this parsing phase, the rule for CREATE VIEW was
holding a reference to the string being parsed for use during
the execution of the CREATE VIEW statement, leading to invalid
memory access later.
The solution is to allocate and copy the SELECT of a CREATE
VIEW statement using the thread memory root, which is set to
the permanent arena of the stored procedure.
mysql-test/r/view.result:
Add test case result for Bug#34587
mysql-test/t/view.test:
Add test case for Bug#34587
sql/sql_lex.h:
Remove start and end position variables. The SELECT of a
CREATE VIEW is now allocated at parse time.
sql/sql_view.cc:
Remove assertion that is not true when the statement is
being re-executed. Use string that was trimmed of leading
and trailing whitespace at parse time.
sql/sql_yacc.yy:
Allocate the SELECT of a CREATE VIEW using the current thread
memory root and remove any leading and trailing whitespace.
The problem is that when a stored procedure is being parsed for
the first execution, the body is copied to a temporary buffer
which is disregarded sometime after the statement is parsed.
And during this parsing phase, the rule for CREATE VIEW was
holding a reference to the string being parsed for use during
the execution of the CREATE VIEW statement, leading to invalid
memory access later.
The solution is to allocate and copy the SELECT of a CREATE
VIEW statement using the thread memory root, which is set to
the permanent arena of the stored procedure.
into zippy.cornsilk.net:/home/cmiller/work/mysql/mysql-5.1-maint
CMakeLists.txt:
Auto merged
configure.in:
Auto merged
libmysql/CMakeLists.txt:
Auto merged
libmysqld/lib_sql.cc:
Auto merged
mysql-test/r/information_schema_db.result:
Auto merged
mysql-test/t/information_schema.test:
Auto merged
sql/CMakeLists.txt:
Auto merged
sql/ha_ndbcluster.cc:
Auto merged
sql/item_cmpfunc.cc:
Auto merged
sql/item_func.cc:
Auto merged
sql/lock.cc:
Auto merged
sql/log_event.cc:
Auto merged
sql/mysql_priv.h:
Auto merged
sql/mysqld.cc:
Auto merged
sql/repl_failsafe.cc:
Auto merged
sql/set_var.cc:
Auto merged
sql/set_var.h:
Auto merged
sql/sp_head.cc:
Auto merged
sql/sql_cache.cc:
Auto merged
sql/sql_class.cc:
Auto merged
sql/sql_class.h:
Auto merged
sql/sql_insert.cc:
Auto merged
sql/sql_lex.cc:
Auto merged
sql/sql_lex.h:
Auto merged
sql/sql_prepare.cc:
Auto merged
sql/sql_repl.cc:
Auto merged
sql/sql_select.cc:
Auto merged
sql/sql_show.cc:
Auto merged
sql/sql_table.cc:
Auto merged
sql/sql_view.cc:
Auto merged
sql/sql_yacc.yy:
Auto merged
sql/structs.h:
Auto merged
sql/table.h:
Auto merged
storage/archive/ha_archive.cc:
Auto merged
storage/myisam/ha_myisam.cc:
Auto merged
storage/myisam/mi_open.c:
Auto merged
storage/myisammrg/ha_myisammrg.cc:
Auto merged
support-files/mysql.spec.sh:
Auto merged
client/mysqlcheck.c:
Manual merge.
mysql-test/r/information_schema.result:
Manual merge.
mysql-test/r/mysqlcheck.result:
Manual merge.
mysql-test/t/mysqlcheck.test:
Manual merge.
sql/slave.cc:
Manual merge.
sql/sql_base.cc:
Manual merge.
sql/sql_delete.cc:
Manual merge.
sql/sql_parse.cc:
Manual merge.
sql/sql_update.cc:
Manual merge.
into zippy.cornsilk.net:/home/cmiller/work/mysql/mysql-5.0-community
CMakeLists.txt:
Auto merged
include/config-win.h:
Auto merged
include/my_sys.h:
Auto merged
libmysql/CMakeLists.txt:
Auto merged
myisam/mi_open.c:
Auto merged
mysql-test/r/information_schema.result:
Auto merged
mysql-test/r/information_schema_db.result:
Auto merged
mysql-test/r/symlink.result:
Auto merged
mysql-test/t/information_schema.test:
Auto merged
mysql-test/t/symlink.test:
Auto merged
mysys/my_symlink2.c:
Auto merged
sql/ha_myisam.cc:
Auto merged
sql/ha_ndbcluster.cc:
Auto merged
sql/item_cmpfunc.cc:
Auto merged
sql/item_func.cc:
Auto merged
sql/log_event.cc:
Auto merged
sql/mysql_priv.h:
Auto merged
sql/mysqld.cc:
Auto merged
sql/set_var.cc:
Auto merged
sql/set_var.h:
Auto merged
sql/slave.cc:
Auto merged
sql/sp_head.cc:
Auto merged
sql/sql_base.cc:
Auto merged
sql/sql_class.cc:
Auto merged
sql/sql_class.h:
Auto merged
sql/sql_insert.cc:
Auto merged
sql/sql_lex.h:
Auto merged
sql/sql_parse.cc:
Auto merged
sql/sql_prepare.cc:
Auto merged
sql/sql_repl.cc:
Auto merged
sql/sql_select.cc:
Auto merged
sql/sql_table.cc:
Auto merged
sql/sql_view.cc:
Auto merged
sql/sql_yacc.yy:
Auto merged
sql/structs.h:
Auto merged
sql/table.h:
Auto merged
support-files/mysql.spec.sh:
Auto merged
win/configure.js:
Auto merged
Makefile.am:
Manual merge.
client/mysqlcheck.c:
Manual merge.
configure.in:
Manual merge.
mysql-test/r/mysqlcheck.result:
Manual merge.
mysql-test/t/mysqlcheck.test:
Manual merge.
sql/sql_delete.cc:
Manual merge.
sql/sql_update.cc:
Manual merge.
into adventure.(none):/home/thek/Development/cpp/mysql-5.1-runtime
sql/mysqld.cc:
Auto merged
sql/sp_head.cc:
Auto merged
sql/sp_head.h:
Auto merged
sql/sql_base.cc:
Auto merged
sql/sql_lex.h:
Auto merged
sql/sql_prepare.cc:
Auto merged
sql/sql_yacc.yy:
Auto merged
