The problem was that the server did not robustly handle a
unilateral roll back issued by the Resource Manager (RM)
due to a resource deadlock within the transaction branch.
By not acknowledging the roll back, the server (TM) would
eventually corrupt the XA transaction state and crash.
The solution is to mark the transaction as rollback-only
if the RM indicates that it rolled back its branch of the
transaction.
mysql-test/r/xa.result:
Add test case result for Bug#28323
mysql-test/t/xa.test:
Add test case for Bug#28323
sql/handler.cc:
Reset XID only at the end of the global transaction.
sql/share/errmsg.txt:
Add new error codes.
sql/sql_class.h:
Remember the error reported by the Resource Manager.
sql/sql_parse.cc:
Rollback the transaction if the Resource Manager reported
a error and rolled back its branch of the transaction.
When running Stored Routines the Status Variable "Questions" was wrongly
incremented. According to the manual it should contain the "number of
statements that clients have sent to the server"
Introduced a new status variable 'questions' to replace the query_id
variable which currently corresponds badly with the number of statements
sent by the client.
The new behavior is ment to be backward compatible with 4.0 and at the
same time work with new features in a similar way.
This is a backport from 6.0
mysql-test/r/status2.result:
Added test case
mysql-test/t/status2.test:
Added test case
sql/mysqld.cc:
Introduced a new status variable 'questions' to replace the query_id
variable which currently corresponds badly with the number of statements
sent by the client.
sql/sql_class.h:
Introduced a new status variable 'questions' to replace the query_id
variable which currently corresponds badly with the number of statements
sent by the client.
sql/sql_parse.cc:
To be backward compatible with 4.0 and at the same time extend the
interpretation of the Question variable, it should be increased on
all COM-commands but COM_STATISTICS, COM_PING, COM_STMT_PREPARE,
COM_STMT_CLOSE and COM_STMT_RESET.
Since COM_QUERY can process multiple statements, there has to be an
extra increase there as well.
sql/sql_show.cc:
Removed deprecated SHOW_QUESTION status code.
sql/structs.h:
Removed deprecated SHOW_QUESTION status code.
The '@' symbol can not be used in the host name according to rfc952.
The fix:
added function check_host_name(LEX_STRING *str)
which checks that all symbols in host name string are valid and
host name length is not more than max host name length
(just moved check_string_length() function from the parser into check_host_name()).
mysql-test/r/create.result:
test result
mysql-test/t/create.test:
test case
sql/mysql_priv.h:
added function check_host_name(LEX_STRING *str)
sql/sql_parse.cc:
added function check_host_name(LEX_STRING *str)
which checks that all symbols in host name string are valid and
host name length is not more than max host name length(HOSTNAME_LENGTH).
sql/sql_yacc.yy:
using newly added function check_host_name()
test_if_data_home_dir fixed to look into real path.
Checks added to mi_open for symlinks into data home directory.
per-file messages:
include/my_sys.h
Bug#32167 another privilege bypass with DATA/INDEX DIRECTORY.
my_is_symlink interface added
include/myisam.h
Bug#32167 another privilege bypass with DATA/INDEX DIRECTORY.
myisam_test_invalid_symlink interface added
myisam/mi_check.c
Bug#32167 another privilege bypass with DATA/INDEX DIRECTORY.
mi_open_datafile calls modified
myisam/mi_open.c
Bug#32167 another privilege bypass with DATA/INDEX DIRECTORY.
code added to mi_open to check for symlinks into data home directory.
mi_open_datafile now accepts 'original' file path to check if it's
an allowed symlink.
myisam/mi_static.c
Bug#32167 another privilege bypass with DATA/INDEX DIRECTORY.
myisam_test_invlaid_symlink defined
myisam/myisamchk.c
Bug#32167 another privilege bypass with DATA/INDEX DIRECTORY.
mi_open_datafile call modified
myisam/myisamdef.h
Bug#32167 another privilege bypass with DATA/INDEX DIRECTORY.
mi_open_datafile interface modified - 'real_path' parameter added
mysql-test/r/symlink.test
Bug#32167 another privilege bypass with DATA/INDEX DIRECTORY.
error codes corrected as some patch now rejected pointing inside datahome
mysql-test/r/symlink.result
Bug#32167 another privilege bypass with DATA/INDEX DIRECTORY.
error messages corrected in the result
mysys/my_symlink.c
Bug#32167 another privilege bypass with DATA/INDEX DIRECTORY.
my_is_symlink() implementsd
my_realpath() now returns the 'realpath' even if a file isn't a symlink
sql/mysql_priv.h
Bug#32167 another privilege bypass with DATA/INDEX DIRECTORY.
test_if_data_home_dir interface
sql/mysqld.cc
Bug#32167 another privilege bypass with DATA/INDEX DIRECTORY.
myisam_test_invalid_symlik set with the 'test_if_data_home_dir'
sql/sql_parse.cc
Bug#32167 another privilege bypass with DATA/INDEX DIRECTORY.
error messages corrected
test_if_data_home_dir code fixed
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)
enabled)
Before this fix, the lexer and parser would treat the ';' character as a
different token (either ';' or END_OF_INPUT), based on convoluted logic,
which failed in simple cases where a stored procedure is implemented as a
single statement, and used in a multi query.
With this fix:
- the character ';' is always parsed as a ';' token in the lexer,
- parsing multi queries is implemented in the parser, in the 'query:' rules,
- the value of thd->client_capabilities, which is the capabilities
negotiated between the client and the server during bootstrap,
is immutable and not arbitrarily modified during parsing (which was the
root cause of the bug)
If during a FLUSH PRIVILEGES the server fails to load the new privilege
tables, the error message is lost. This patch is a back port from 5.1 which
adresses this issue by setting the server in an error state if a failure
occurrs.
This patch also corrects an incorrect variable assignment which might
cause an error state to be reverted by coincidence.
sql/sql_parse.cc:
* Set error state if acl_reload or grant_reload fails.
* Fix bad variable assignment which cancels previous error status.
The bool data type was redefined to BOOL (4 bytes on windows).
Removed the #define and fixed some of the warnings that were uncovered
by this.
Note that the fix also disables 2 warnings :
4800 : 'type' : forcing value to bool 'true' or 'false' (performance warning)
4805: 'operation' : unsafe mix of type 'type' and type 'type' in operation
These warnings will be handled in a separate bug, as they are performance related or bogus.
Fixed to int the return type of functions that return more than
2 distinct values.
CMakeLists.txt:
Bug #26461: disable the C4800 and C4805 warnings temporarily
include/config-win.h:
Bug #26461:
- no need for this define for Windows.
- windows C++ compilers have a bool type
include/my_global.h:
Bug #26461: removed bool_defined (no longer needed)
sql/handler.h:
Bug #26461: bool functions must return boolean values
sql/mysql_priv.h:
Bug #26461: fixed return type of functions that return more than
2 distinct values.
sql/procedure.h:
Bug #26461: fixed return type of functions that return more than
2 distinct values.
sql/sql_acl.cc:
Bug #26461: fixed return type of functions that return more than
2 distinct values.
sql/sql_acl.h:
Bug #26461: fixed return type of functions that return more than
2 distinct values.
sql/sql_analyse.cc:
Bug #26461: fixed return type of functions that return more than
2 distinct values.
sql/sql_analyse.h:
Bug #26461: fixed return type of functions that return more than
2 distinct values.
sql/sql_base.cc:
Bug #26461: fixed return type of functions that return more than
2 distinct values.
sql/sql_db.cc:
Bug #26461: fixed return type of functions that return more than
2 distinct values.
sql/sql_delete.cc:
Bug #26461: fixed return type of functions that return more than
2 distinct values.
sql/sql_load.cc:
Bug #26461: fixed return type of functions that return more than
2 distinct values.
sql/sql_parse.cc:
Bug #26461: fixed return type of functions that return more than
2 distinct values.
sql/sql_prepare.cc:
Bug #26461: fixed return type of functions that return more than
2 distinct values.
sql/sql_update.cc:
Bug #26461: fixed return type of functions that return more than
2 distinct values.
into kaamos.(none):/data/src/opt/mysql-5.0-opt
client/mysql.cc:
Auto merged
sql/filesort.cc:
Auto merged
sql/item.cc:
Auto merged
sql/item.h:
Auto merged
sql/item_func.cc:
Auto merged
sql/mysqld.cc:
Auto merged
sql/sql_parse.cc:
Auto merged
sql/sql_yacc.yy:
Auto merged
tests/mysql_client_test.c:
Auto merged
mysql-test/r/view.result:
Manual merge.
mysql-test/t/view.test:
Manual merge.
scripts/mysql_config.sh:
Manual merge.
added new function test_if_data_home_dir() which checks that
path does not contain mysql data home directory.
Using of mysql data home directory in
DATA DIRECTORY & INDEX DIRECTORY is disallowed.
mysql-test/r/symlink.result:
test result
mysql-test/t/symlink.test:
test case
sql/mysql_priv.h:
new variable mysql_unpacked_real_data_home
sql/mysqld.cc:
new variable mysql_unpacked_real_data_home
sql/sql_parse.cc:
added new function test_if_data_home_dir() which checks that
path does not contain mysql data home directory.
Using of mysql data home directory in
DATA DIRECTORY & INDEX DIRECTORY is disallowed.
- Replace per-thread signal()'s with SetUnhandledExceptionFilter().
The only remaining signal() is for SIGABRT (default abort()
handler in VS2005 is broken, i.e removes user exception filter)
- remove MessageBox()'es from error handling code
- Windows port for print_stacktrace() and write_core()
- Cleanup, removed some unused functions
sql/CMakeLists.txt:
Implement stack tracing on and generating crash dumps on Windows
sql/mysqld.cc:
Correct signal handling on Windows.
- For console events, like CTRL-C use SetConsoleCtrlHandler
- For exceptions like access violation, use SetUnhandledExceptionFilter
- For SIGABRT generate exception via __debugbreak() intrinsic
if built with VS2005 and later , since default SIGABRT handler
replaces unhandled exception filter specified by user
- make provisions to debug exception filter, as it is not trivial
(should be compiled with /DDEBUG_UNHANDLED_EXCEPTION_FILTER)
sql/sql_parse.cc:
Remove message box from windows signal handler.
The only thread specific handler left is for SIGABRT,
which is broken on VS2005 and later (user specified unhandled exception
filter gets overwritten)
sql/stacktrace.c:
Stack tracing and generating crash dumps on Windows
sql/stacktrace.h:
Implement print_stacktrace and write_core on Windows
into dl145h.mysql.com:/data0/mkindahl/mysql-5.0-rpl-merge
include/my_sys.h:
Auto merged
mysql-test/r/blackhole.result:
Auto merged
mysql-test/r/case.result:
Auto merged
mysql-test/r/mysqlbinlog2.result:
Auto merged
mysql-test/t/blackhole.test:
Auto merged
mysql-test/t/case.test:
Auto merged
sql/set_var.cc:
Auto merged
sql/sql_acl.cc:
Auto merged
sql/sql_parse.cc:
Auto merged
Here is the scenario that causes the failure.(by Mats)
1. The to-be corrupt log event (let's call it X), is split into two
packets B and C on the network level (net_write_buff()). The parts
are X = (x',x''). The part x' ends up in packet B and part x''
ends up in packet C. Prior to the corrupt event X, the event Y has
been written successfully, but has been split into two packets as
well, which we call (y',y'').
2. The master sends packet A = (y'',x') to the slave, increases the
packet sequence number, the slave receives the packet, but fails
to reply before the master gets a timeout.
3. Since the master got a timeout, it reports failure, and aborts
sending the binary log by exiting mysql_binlog_send(). However, it
leaves the buffer intact, still holding y'' (but not x', since the
write_pos is not increased).
4. After exiting mysql_binlog_send(), the master does a
disconnection of the client thread, which involves sending an
error message e to the client (i.e., the slave).
5. In this case, net_write_buff() is used again, but this time the
old contents of the packet is used so that the new packet is
D = (y'',e). Note that this will use a new packet sequence number,
since the packet number was increased in step 2.
6. The slave receives the tail y'' of the Y log event, concatenates
this with x' (which it already received), and writes the event
(x',y'') it to the relay log since it hasn't noticed anything is
amiss.
7. It then tries to read more bytes, which is either e (if the length
given for X just happened to match the length given for Y, or just
plain garbage because the slave is out of sync with what is
actually sent.
8. After a while, the SQL thread tries to execute the event (x',y''),
which is very likely to be just nonsense.
The problem can be fixed by not resetting net->error after the call of
mysql_binlog_send, so the error message will not be sent and the connection
will be closed.
sql/sql_parse.cc:
Do not reset net->error, if net->error == 2, we should not try to use the connection again
When read_only option was enabled, a user without SUPER privilege could
perform CREATE DATABASE and DROP DATABASE operations.
This patch adds a check to make sure this isn't possible. It also attempts to
simplify the logic used to determine if relevant tables are updated,
making it more human readable.
mysql-test/r/read_only.result:
Updated result file
mysql-test/t/read_only.test:
A test case is added which shows that it is not possible to drop or create a
database in read-only mode despite having the GRANT permissions to do so,
SUPER user excepted.
sql/sql_parse.cc:
- Simplified complex predicate by grouping it in a read friendly way.
- Added predicate to fail on database updates while running in read-only
mode.
into lambda.hsd1.co.comcast.net.:/home/malff/TREE/mysql-5.0-rt-merge
sql/mysqld.cc:
Auto merged
sql/sp_head.cc:
Auto merged
sql/sql_parse.cc:
Auto merged
FLUSH TABLES WITH READ LOCK fails to properly detect write locked
tables when running under low priority updates.
The problem is that when trying to aspire a global read lock, the
reload_acl_and_cache() function fails to properly check if the thread
has a low priority write lock, which later my cause a server crash or
deadlock.
The solution is to simple check if the thread has any type of the
possible exclusive write locks.
mysql-test/r/flush.result:
Add test case result for Bug#32528
mysql-test/t/flush.test:
Add test case for Bug#32528
sql/sql_parse.cc:
Although it should not matter under LOCK TABLES, use TL_WRITE_ALLOW_WRITE
to emphasize that it should fail in case of any write lock.
into mysql.com:/home/bar/mysql-work/mysql-5.0-rpl-merge
mysql-test/r/ctype_utf8.result:
Auto merged
mysql-test/r/func_regexp.result:
Auto merged
mysql-test/t/ctype_utf8.test:
Auto merged
mysql-test/t/func_regexp.test:
Auto merged
sql/item_cmpfunc.cc:
Auto merged
sql/item_cmpfunc.h:
Auto merged
sql/sql_class.h:
Auto merged
sql/sql_insert.cc:
Auto merged
sql/sql_parse.cc:
Auto merged
sql/sql_update.cc:
Auto merged
mysql-test/r/ctype_ucs.result:
After merge fix
mysql-test/t/ctype_ucs.test:
After merge fix
into mysql.com:/home/bar/mysql-work/mysql-5.0-rpl-mr
client/mysql.cc:
Auto merged
mysql-test/r/ctype_euckr.result:
Auto merged
mysql-test/r/ctype_uca.result:
Auto merged
sql/mysqld.cc:
Auto merged
sql/sp_head.cc:
Auto merged
sql/sql_parse.cc:
Auto merged
strings/ctype-euc_kr.c:
Auto merged
into mysql.com:/home/gluh/MySQL/Merge/5.0-opt
client/mysqldump.c:
Auto merged
include/config-win.h:
Auto merged
libmysql/libmysql.c:
Auto merged
myisam/sort.c:
Auto merged
mysql-test/r/func_sapdb.result:
Auto merged
mysql-test/r/variables.result:
Auto merged
mysql-test/t/variables.test:
Auto merged
sql/field.cc:
Auto merged
sql/ha_innodb.cc:
Auto merged
sql/item_func.cc:
Auto merged
sql/item_sum.cc:
Auto merged
sql/item_timefunc.h:
Auto merged
sql/mysql_priv.h:
Auto merged
sql/set_var.cc:
Auto merged
sql/sql_acl.cc:
Auto merged
sql/sql_base.cc:
Auto merged
sql/sql_parse.cc:
Auto merged
sql/sql_select.cc:
Auto merged
sql/sql_yacc.yy:
Auto merged
tests/mysql_client_test.c:
Auto merged
mysql-test/r/type_datetime.result:
manual merge
mysql-test/r/type_decimal.result:
manual merge
mysql-test/t/type_datetime.test:
manual merge
mysql-test/t/type_decimal.test:
manual merge
sql/item.cc:
manual merge
The root cause of the issue was that the CREATE FUNCTION grammar,
for User Defined Functions, was using the sp_name rule.
The sp_name rule is intended for fully qualified stored procedure names,
like either ident.ident, or just ident but with a default database
implicitly selected.
A UDF does not have a fully qualified name, only a name (ident), and should
not use the sp_name grammar fragment during parsing.
The fix is to re-organize the CREATE FUNCTION grammar, to better separate:
- creating UDF (no definer, can have AGGREGATE, simple ident)
- creating Stored Functions (definer, no AGGREGATE, fully qualified name)
With the test case provided, another issue was exposed which is also fixed:
the DROP FUNCTION statement was using sp_name and also failing when no database
is implicitly selected, when droping UDF functions.
The fix is also to change the grammar so that DROP FUNCTION works with
both the ident.ident syntax (to drop a stored function), or just the ident
syntax (to drop either a UDF or a Stored Function, in the current database)
mysql-test/r/sp-error.result:
Adjust test results
mysql-test/r/udf.result:
Adjust test results
mysql-test/t/sp-error.test:
Adjust test results
mysql-test/t/udf.test:
Adjust test results
sql/sql_parse.cc:
CREATE UDF FUNCTION does not use a fully qualified name.
sql/sql_yacc.yy:
Fix grammar for CREATE / DROP FUNCTION, FOR udf
Improve error messages for select no_such_function()
similar to bug_27716, but it was stressed on in the synopsis on that there is another
side of the artifact affecting behaviour in transaction.
Fixed with deploying multi_delete::send_error() - otherwise never called - and refining its logic
to perform binlogging job if needed.
The changeset includes the following side effects:
- added tests to check bug_23333's scenarios on the mixture of tables for multi_update;
- fixes bug@30763 with two-liner patch and a test coinciding to one added for bug_23333.
mysql-test/r/innodb.result:
results changed
mysql-test/r/mix_innodb_myisam_binlog.result:
results changed
mysql-test/r/multi_update.result:
results changed
mysql-test/t/innodb.test:
trans table specific test added
mysql-test/t/mix_innodb_myisam_binlog.test:
multi-update and multi-delete of mixure of ta and not-ta tables tests added (relates to bug_23333).
mysql-test/t/multi_update.test:
testing another branch of mult-delete: send_eof() (binloggin there), send_error (early return)
sql/sql_class.h:
a new flag to designate the fact the statement's error has been handled.
The flag is checked by ::send_error() methods (multi_update and _delete classes)
sql/sql_delete.cc:
expanding multi_delete::send_error to
1. early return if error_handled == t
2. binlogging locally if there was a non-trans table modified side effect
sql/sql_parse.cc:
adding multi_update::send_error which can perform binlogging and rollback job in needed
sql/sql_update.cc:
issues relating to
1. bug_27716 with zeroing of `updated' to serve as the flag of early return from send_error().
The flag is changed to be a new member error_handled; also moved outside binlogging branch.
The reason for this change is that bug_23333 fixes were pushed after the bug_27716's and they
left this flaw (also no test coverage).
2. bug_30763 with assertion on trans_safe. I decide to make 2 liner fix for that bug here instead of to remove
those two assertions. This new bug test case is the same as for multi-update on the mixure of tables.
The rational for this fix:
presumption for mutli_update::trans_safe to be set to zero at
multi_update::multi_update or multi_update::initialize_tables() is incorrect.
trans_safe := false should happen only when a non-transactional table gets modified.
Therefore, at initialization the member must be be set to true.
into bodhi.(none):/opt/local/work/mysql-5.0-runtime
mysql-test/r/sp.result:
Auto merged
mysql-test/t/sp.test:
Auto merged
sql/sql_parse.cc:
Auto merged
added check for hidden I_S tables for 'show columns|keys' commands
mysql-test/r/information_schema.result:
test result
mysql-test/t/information_schema.test:
test case
sql/sql_parse.cc:
added check for hidden I_S tables for 'show columns|keys' commands
active_mi has been reset (shutdown) at the time of quering with
SHOW SLAVE STATUS so that
at handling of SHOW an attempt to read its members segfaults.
Fixed with checking the value of active_mi before to call show_master_info()
Merely send_ok() is invoked when active_mi does not exist.
A test can not be easiely written.
Notice, there are more analogical cases in the code which require a similar
treatment (to be reported as a bug separately).
sql/sql_parse.cc:
Ignore reporting and send only OK if master info struct has been destoyed.
As this must be at shutdown merely a warning is sent to the client.
The problem was that aborted_threads variable was updated
twice when a client connection had been aborted.
The fix is to refactor a code to have aborted_threads updated
only in one place.
sql/mysql_priv.h:
Make do_command() a private function.
sql/sql_parse.cc:
1. Make do_command() a private function;
2. Update aborted_threads in the only one place.
Use view db name as thread default database, in order to ensure
that the view is parsed and prepared correctly.
mysql-test/r/sp.result:
test result
mysql-test/t/sp.test:
test case
sql/sql_parse.cc:
copy thd->db_length to table_list->db_length
sql/sql_view.cc:
Use view db name as thread default database, in order to ensure
that the view is parsed and prepared correctly.
When dumping database from a 4.x server, the mysqldump client
inserted a delimiter sign inside special commentaries of the form:
/*!... CREATE DATABASE IF NOT EXISTS ... ;*/
During restoration that dump file was splitten by delimiter signs on
the client side, and the rest of some commentary strings was prepended
to following statements.
The 4x_server_emul test case option has been added for use with the
DBUG_EXECUTE_IF debugging macro. This option affects debug server
builds only to emulate particular behavior of a 4.x server for
the mysqldump client testing. Non-debugging builds are not affected.
mysql-test/r/mysqldump-compat.result:
Added test case for bug #30126.
mysql-test/t/mysqldump-compat.opt:
Added test case for bug #30126.
mysql-test/t/mysqldump-compat.test:
Added test case for bug #30126.
sql/sql_parse.cc:
Fixed bug #30126.
The mysqldump client uses the "SHOW CREATE DATABASE" query to
obtain the "CREATE DATABASE" statement from that database.
The 4.x server doesn't recognise that query, and mysqldump
forms the "CREATE DATABASE" statement from scratch.
That statement was formed incorrectly.
To enforce the mysqldump client to create that statement from
scratch, debugging code has been added to the mysql_execute_command
function: in tcase of the --loose-debug=d,4x_server_emul option,
the server returns parse error to client to emulate old behaviour.
The 4x_server_emul test case option has been added for use with the
DBUG_EXECUTE_IF debugging macro. This option affects debug server
builds only to emulate particular behavior of a 4.x server for
the mysqldump client testing. Non-debugging builds are not affected.
client/mysqldump.c:
Fixed bug #30126.
The init_dumping_tables function has been modified to output semicolon
outside of commentaries.
The SELECT query with more than 31 nested dependent SELECT queries returned
wrong result.
New error message has been added: ER_TOO_HIGH_LEVEL_OF_NESTING_FOR_SELECT.
It will be reported as: "Too high level of nesting for select".
sql/sql_parse.cc:
Fixed bug #27352.
The Item_sum::register_sum_func method has been modified to return
TRUE on exceeding of allowed level of SELECT nesting and to report
corresponding error message.
sql/unireg.h:
Fixed bug #27352.
Constant definition has been added: maximal allowed level of SELECT nesting.
mysql-test/t/select.test:
Updated test case for bug #27352.
mysql-test/r/select.result:
Updated test case for bug #27352.
sql/share/errmsg.txt:
Fixed bug #27352.
New error message has been added: ER_TOO_HIGH_LEVEL_OF_NESTING_FOR_SELECT.
Problem: thd->thread_specific_used flag is not set executing a statement
containig connection_id() function using PS protocol, that leads to
improper binlog event creation.
Fix: set the flag in the Item_func_connection_id::fix_fields().
sql/item_create.cc:
Fix for bug #30200: mysqlbinlog.test: connection_id() not restored under ps-protocol
- set the thd->thread_specific_used flag in the Item_func_connection_id::fix_fields()
to have it properly set using PS protocol as well.
sql/item_func.cc:
Fix for bug #30200: mysqlbinlog.test: connection_id() not restored under ps-protocol
- set the thd->thread_specific_used flag in the Item_func_connection_id::fix_fields()
to have it properly set using PS protocol as well.
sql/sql_parse.cc:
Fix for bug #30200: mysqlbinlog.test: connection_id() not restored under ps-protocol
- reset the thd->thread_specific_used flag in the mysql_reset_thd_for_next_command().
Bug #27417 thd->no_trans_update.stmt lost value inside of SF-exec-stack
Once had been set the flag might later got reset inside of a stored routine
execution stack.
The reason was in that there was no check if a new statement started at time
of resetting.
The artifact affects most of binlogable DML queries. Notice, that multi-update
is wrapped up within
bug@27716 fix, multi-delete bug@29136.
Fixed with saving parent's statement flag of whether the statement modified
non-transactional table, and unioning (merging) the value with that was gained
in mysql_execute_command.
Resettling thd->no_trans_update members into thd->transaction.`member`;
Asserting code;
Effectively the following properties are held.
1. At the end of a substatement thd->transaction.stmt.modified_non_trans_table
reflects the fact if such a table got modified by the substatement.
That also respects THD::really_abort_on_warnin() requirements.
2. Eventually thd->transaction.stmt.modified_non_trans_table will be computed as
the union of the values of all invoked sub-statements.
That fixes this bug#27417;
Computing of thd->transaction.all.modified_non_trans_table is refined to base to
the stmt's value for all the case including insert .. select statement which
before the patch had an extra issue bug@28960.
Minor issues are covered with mysql_load, mysql_delete, and binloggin of insert in
to temp_table select.
The supplied test verifies limitely, mostly asserts. The ultimate testing is defered
for bug@13270, bug@23333.
mysql-test/r/mix_innodb_myisam_binlog.result:
results changed
mysql-test/t/mix_innodb_myisam_binlog.test:
regression test incl the related bug#28960.
sql/ha_ndbcluster.cc:
thd->transaction.{all,stmt}.modified_non_trans_table
instead of
thd->no_trans_update.{all,stmt}
sql/handler.cc:
thd->transaction.{all,stmt}.modified_non_trans_table
instead of
thd->no_trans_update.{all,stmt}
sql/handler.h:
new member added
sql/log.cc:
thd->transaction.{all,stmt}.modified_non_trans_table
instead of
thd->no_trans_update.{all,stmt}
sql/set_var.cc:
thd->transaction.{all,stmt}.modified_non_trans_table
instead of
thd->no_trans_update.{all,stmt}
sql/sp_head.cc:
thd->transaction.{all,stmt}.modified_non_trans_table
instead of
thd->no_trans_update.{all,stmt}
and saving and merging stmt's flag at the end of a substatement.
sql/sql_class.cc:
thd->transaction.{all,stmt}.modified_non_trans_table
instead of
thd->no_trans_update.{all,stmt}
sql/sql_class.h:
thd->transaction.{all,stmt}.modified_non_trans_table
instead of
thd->no_trans_update.{all,stmt}
sql/sql_delete.cc:
correcting basic delete incl truncate branch and multi-delete queries to set
stmt.modified_non_trans_table;
optimization to set the flag at the end of per-row loop;
multi-delete still has an extra issue similar to bug#27716 of multi-update
- to be address with bug_29136 fix.
sql/sql_insert.cc:
thd->transaction.{all,stmt}.modified_non_trans_table
instead of
thd->no_trans_update.{all,stmt}
sql/sql_load.cc:
eliminating a separate issue where the stmt flag was saved and re-stored after
write_record that actually could change it and the change would be lost but
should remain permanent;
thd->transaction.{all,stmt}.modified_non_trans_table
instead of
thd->no_trans_update.{all,stmt}
sql/sql_parse.cc:
initialization to transaction.stmt.modified_non_trans_table at the common part
of all types of statements processing - mysql_execute_command().
sql/sql_table.cc:
moving the reset up to the mysql_execute_command() caller
sql/sql_update.cc:
correcting update query case (multi-update part of the issues covered by other
bug#27716 fix)
thd->transaction.{all,stmt}.modified_non_trans_table
instead of
thd->no_trans_update.{all,stmt}
into bodhi.(none):/opt/local/work/mysql-5.0-runtime
mysql-test/t/sp.test:
Auto merged
sql/item.h:
Auto merged
sql/sql_parse.cc:
Auto merged
sql/sql_show.cc:
Auto merged
sql/sql_yacc.yy:
Auto merged
mysql-test/r/innodb_mysql.result:
Manual merge.
mysql-test/t/innodb_mysql.test:
Manual merge.
selected prior: ensure the fix also works for information_schema
tables.
sql/sql_parse.cc:
Ensure the fix for Bug#29050 works for information_schema tables.
causes full table lock on innodb table.
Also fixes Bug#28502 Triggers that update another innodb table
will block on X lock unnecessarily (duplciate).
Code review fixes.
Both bugs' synopses are misleading: InnoDB table is
not X locked. The statements, however, cannot proceed concurrently,
but this happens due to lock conflicts for tables used in triggers,
not for the InnoDB table.
If a user had an InnoDB table, and two triggers, AFTER UPDATE and
AFTER INSERT, competing for different resources (e.g. two distinct
MyISAM tables), then these two triggers would not be able to execute
concurrently. Moreover, INSERTS/UPDATES of the InnoDB table would
not be able to run concurrently.
The problem had other side-effects (see respective bug reports).
This behavior was a consequence of a shortcoming of the pre-locking
algorithm, which would not distinguish between different DML operations
(e.g. INSERT and DELETE) and pre-lock all the tables
that are used by any trigger defined on the subject table.
The idea of the fix is to extend the pre-locking algorithm to keep track,
for each table, what DML operation it is used for and not
load triggers that are known to never be fired.
mysql-test/r/trigger-trans.result:
Update results (Bug#26141)
mysql-test/r/trigger.result:
Update results (Bug#28502)
mysql-test/t/trigger-trans.test:
Add a test case for Bug#26141 mixing table types in trigger causes
full table lock on innodb table.
mysql-test/t/trigger.test:
Add a test case for Bug#28502 Triggers that update another innodb
table will block echo on X lock unnecessarily. Add more test
coverage for triggers.
sql/item.h:
enum trg_event_type is needed in table.h
sql/sp.cc:
Take into account table_list->trg_event_map when determining
what tables to pre-lock.
After this change, if we attempt to fire a
trigger for which we had not pre-locked any tables, error
'Table was not locked with LOCK TABLES' will be printed.
This, however, should never happen, provided the pre-locking
algorithm has no programming bugs.
Previously a trigger key in the sroutines hash was based on the name
of the table the trigger belongs to. This was possible because we would
always add to the pre-locking list all the triggers defined for a table when
handling this table.
Now the key is based on the name of the trigger, owing
to the fact that a trigger name must be unique in the database it
belongs to.
sql/sp_head.cc:
Generate sroutines hash key in init_spname(). This is a convenient
place since there we have all the necessary information and can
avoid an extra alloc.
Maintain and merge trg_event_map when adding and merging elements
of the pre-locking list.
sql/sp_head.h:
Add ,m_sroutines_key member, used when inserting the sphead for a
trigger into the cache of routines used by a statement.
Previously the key was based on the table name the trigger belonged
to, since for a given table we would add to the sroutines list
all the triggers defined on it.
sql/sql_lex.cc:
Introduce a new lex step: set_trg_event_type_for_tables().
It is called when we have finished parsing but before opening
and locking tables. Now this step is used to evaluate for each
TABLE_LIST instance which INSERT/UPDATE/DELETE operation, if any,
it is used in.
In future this method could be extended to aggregate other information
that is hard to aggregate during parsing.
sql/sql_lex.h:
Add declaration for set_trg_event_type_for_tables().
sql/sql_parse.cc:
Call set_trg_event_type_for_tables() after MYSQLparse(). Remove tabs.
sql/sql_prepare.cc:
Call set_trg_event_type_for_tables() after MYSQLparse().
sql/sql_trigger.cc:
Call set_trg_event_type_for_tables() after MYSQLparse().
sql/sql_trigger.h:
Remove an obsolete member.
sql/sql_view.cc:
Call set_trg_event_type_for_tables() after MYSQLparse().
sql/sql_yacc.yy:
Move assignment of sp_head::m_type before calling sp_head::init_spname(),
one is now used inside another.
sql/table.cc:
Implement TABLE_LIST::set_trg_event_map() - a method that calculates
wh triggers may be fired on this table when executing a statement.
sql/table.h:
Add missing declarations.
Move declaration of trg_event_type from item.h (it will be needed for
trg_event_map bitmap when we start using Bitmap template instead
of uint8).
Problem: logging queries not using indexes we check a special flag which
is set only at the server startup and is not changing with a corresponding
server variable together.
Fix: check the variable value instead of the flag.
mysql-test/r/show_check.result:
Fix for bug #28808: log_queries_not_using_indexes variable dynamic change is ignored
- test result.
mysql-test/t/show_check.test:
Fix for bug #28808: log_queries_not_using_indexes variable dynamic change is ignored
- test case.
sql/mysqld.cc:
Fix for bug #28808: log_queries_not_using_indexes variable dynamic change is ignored
- SPECIAL_LOG_QUERIES_NOT_USING_INDEXES is not used anymore.
sql/sql_parse.cc:
Fix for bug #28808: log_queries_not_using_indexes variable dynamic change is ignored
- check opt_log_queries_not_using_indexes instead of
SPECIAL_LOG_QUERIES_NOT_USING_INDEXES flag.
sql/unireg.h:
Fix for bug #28808: log_queries_not_using_indexes variable dynamic change is ignored
- SPECIAL_LOG_QUERIES_NOT_USING_INDEXES is not used anymore.
fails if a database is not selected prior.
The problem manifested itself when a user tried to
create a routine that had non-fully-qualified identifiers in its bodies
and there was no current database selected.
This is a regression introduced by the fix for Bug 19022:
The patch for Bug 19022 changes the code to always produce a warning
if we can't resolve the current database in the parser.
In this case this was not necessary, since even though the produced
parsed tree was incorrect, we never re-use sphead
that was obtained at first parsing of CREATE PROCEDURE.
The sphead that is anyhow used is always obtained through db_load_routine,
and there we change the current database to sphead->m_db before
calling yyparse.
The idea of the fix is to resolve the current database directly using
lex->sphead->m_db member when parsing a stored routine body, when
such is present.
This patch removes the need to reset the current database
when loading a trigger or routine definition into SP cache.
The redundant code will be removed in 5.1.
mysql-test/r/sp.result:
Update test results (Bug#29050)
mysql-test/r/trigger.result:
Update results.
mysql-test/t/sp.test:
Add a test case for Bug#29050
mysql-test/t/trigger.test:
Fix wrong behavior covered with tests.
sql/sql_lex.cc:
Implement st_lex::copy_db_to().
sql/sql_lex.h:
Declare st_lex::copy_db_to().
sql/sql_parse.cc:
Use st_lex::copy_db_to() in add_table_to_list, rather than
THD::copy_db_to(). The former will use the database of the sphead,
if we're parsing a stored routine, not the default database in
THD. The default database is needed to initialize tables->db
when the database part was not explicitly specified in the identifier.
sql/sql_yacc.yy:
Use st_lex::copy_db_to() in the parser, rather than
THD::copy_db_to(). The former will use the database of the sphead,
if we're parsing a stored routine, not the default database in
THD.
LOCK TABLES takes a list of tables to lock. It may lock several
tables successfully and then encounter a tables that it can't lock,
e.g. because it's locked. In such case it needs to undo the locks on
the already locked tables. And it does that. But it has also notified
the relevant table storage engine handlers that they should lock.
The only reliable way to ensure that the table handlers will give up
their locks is to end the transaction. This is what UNLOCK TABLE
does : it ends the transaction if there were locked tables by LOCK
tables.
It is possible to end the transaction when the lock fails in
LOCK TABLES because LOCK TABLES ends the transaction at its start
already.
Fixed by ending (again) the transaction when LOCK TABLES fails to
lock a table.
mysql-test/r/innodb_mysql.result:
Bug #29154: test case
mysql-test/t/innodb_mysql.test:
Bug #29154: test case
sql/sql_parse.cc:
Bug #29154: end the trasaction at a failing
LOCK TABLES so the handler can free its locks.
into adventure.(none):/home/thek/Development/cpp/mysql-5.0-runtime
sql/sql_class.h:
Auto merged
sql/sql_parse.cc:
Auto merged
sql/sql_prepare.cc:
Auto merged
sql/sql_view.cc:
Auto merged
sql/sql_yacc.yy:
Auto merged
