An error occurred fetching the project authors.
- 26 Aug, 2008 2 commits
-
-
He Zhenxing authored
-
He Zhenxing authored
-
- 19 Aug, 2008 1 commit
-
-
Sergey Petrunia authored
- Before sending EOF, check if we've already sent an error.
-
- 14 Jul, 2008 1 commit
-
-
Marc Alff authored
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.
-
- 19 Jun, 2008 1 commit
-
-
Andrei Elkin authored
The crash appeared to be a result of allocating an instance of Discrete_interval automatically that that was referred in out-of-declaration scope. Fixed with correcting backing up and restoring scheme of auto_inc_intervals_forced, introduced by bug#33029, by means of shallow copying; added simulation code that forces executing those fixes of the former bug that targeted at master-and-slave having incompatible bug#33029-prone versions.
-
- 20 May, 2008 1 commit
-
-
kostja@bodhi.(none) authored
PREPARE": rename members, methods, classes to follow the spec (a code review request)
-
- 13 May, 2008 1 commit
-
-
gkodinov/kgeorge@magare.gmz authored
subselects into account It is forbidden to use the SELECT INTO construction inside UNION statements unless on the last SELECT of the union. The parser records whether it has seen INTO or not when parsing a UNION statement. But if the INTO was legally used in an outer query, an error is thrown if UNION is seen in a subquery. Fixed in 5.0 by remembering the nesting level of INTO tokens and mitigate the error unless it collides with the UNION.
-
- 16 Apr, 2008 1 commit
-
-
kostja@bodhi.(none) authored
Add metadata validation to ~20 more SQL commands. Make sure that these commands actually work in ps-protocol, since until now they were enabled, but not carefully tested. Fixes the ml003 bug found by Matthias during internal testing of the patch.
-
- 08 Apr, 2008 1 commit
-
-
kostja@dipika.(none) authored
WL#4165 Prepared statements: validation WL#4166 Prepared statements: automatic re-prepare Fixes Bug#27430 Crash in subquery code when in PS and table DDL changed after PREPARE Bug#27690 Re-execution of prepared statement after table was replaced with a view crashes Bug#27420 A combination of PS and view operations cause error + assertion on shutdown The basic idea of the patch is to keep track of table metadata between prepared statement prepare and execute. If some table used in the statement has changed, the prepared statement is re-prepared before execution. See WL#4165 and WL#4166 contents and comments in the code for details of the implementation.
-
- 29 Mar, 2008 1 commit
-
-
aelkin/andrei@mysql1000.(none) authored
If a binlog file is manually replaced with a namesake directory the internal purging did not handle the error of deleting the file so that eventually a post-execution guards fires an assert. Fixed with reusing a snippet of code for bug@18199 to tolerate lack of the file but no other error at an attempt to delete it. The same applied to the index file deletion. The cset carries pieces of manual merging.
-
- 17 Mar, 2008 1 commit
-
-
davi@buzz.(none) authored
-
- 14 Mar, 2008 2 commits
-
-
hezx@mail.hezx.com authored
using a trig in SP For all 5.0 and up to 5.1.12 exclusive, when a stored routine or trigger caused an INSERT into an AUTO_INCREMENT column, the generated AUTO_INCREMENT value should not be written into the binary log, which means if a statement does not generate AUTO_INCREMENT value itself, there will be no Intvar event (SET INSERT_ID) associated with it even if one of the stored routine or trigger caused generation of such a value. And meanwhile, when executing a stored routine or trigger, it would ignore the INSERT_ID value even if there is a INSERT_ID value available set by a SET INSERT_ID statement. Starting from MySQL 5.1.12, the generated AUTO_INCREMENT value is written into the binary log, and the value will be used if available when executing the stored routine or trigger. Prior fix of this bug in MySQL 5.0 and prior MySQL 5.1.12 (referenced as the buggy versions in the text below), when a statement that generates AUTO_INCREMENT value by the top statement was executed in the body of a SP, all statements in the SP after this statement would be treated as if they had generated AUTO_INCREMENT by the top statement. When a statement that did not generate AUTO_INCREMENT value by the top statement but by a function/trigger called by it, an erroneous Intvar event would be associated with the statement, this erroneous INSERT_ID value wouldn't cause problem when replicating between masters and slaves of 5.0.x or prior 5.1.12, because the erroneous INSERT_ID value was not used when executing functions/triggers. But when replicating from buggy versions to 5.1.12 or newer, which will use the INSERT_ID value in functions/triggers, the erroneous value will be used, which would cause duplicate entry error and cause the slave to stop. The patch for 5.1 fixed it to ignore the SET INSERT_ID value when executing functions/triggers if it is replicating from a master of buggy versions, another patch for 5.0 fixed it not to generate the erroneous Intvar event.
-
hezx@mail.hezx.com authored
using a trig in SP For all 5.0 and up to 5.1.12 exclusive, when a stored routine or trigger caused an INSERT into an AUTO_INCREMENT column, the generated AUTO_INCREMENT value should not be written into the binary log, which means if a statement does not generate AUTO_INCREMENT value itself, there will be no Intvar event (SET INSERT_ID) associated with it even if one of the stored routine or trigger caused generation of such a value. And meanwhile, when executing a stored routine or trigger, it would ignore the INSERT_ID value even if there is a INSERT_ID value available set by a SET INSERT_ID statement. Starting from MySQL 5.1.12, the generated AUTO_INCREMENT value is written into the binary log, and the value will be used if available when executing the stored routine or trigger. Prior fix of this bug in MySQL 5.0 and prior MySQL 5.1.12 (referenced as the buggy versions in the text below), when a statement that generates AUTO_INCREMENT value by the top statement was executed in the body of a SP, all statements in the SP after this statement would be treated as if they had generated AUTO_INCREMENT by the top statement. When a statement that did not generate AUTO_INCREMENT value by the top statement but by a function/trigger called by it, an erroneous Intvar event would be associated with the statement, this erroneous INSERT_ID value wouldn't cause problem when replicating between masters and slaves of 5.0.x or prior 5.1.12, because the erroneous INSERT_ID value was not used when executing functions/triggers. But when replicating from buggy versions to 5.1.12 or newer, which will use the INSERT_ID value in functions/triggers, the erroneous value will be used, which would cause duplicate entry error and cause the slave to stop. The patch for 5.0 fixed it not to generate the erroneous Intvar event, another patch for 5.1 fixed it to ignore the SET INSERT_ID value when executing functions/triggers if it is replicating from a master of buggy versions.
-
- 05 Mar, 2008 1 commit
-
-
cmiller@zippy.cornsilk.net authored
The DBUG code emits the current value of the proc_info member of THD, which may be set to NULL. It was wrong to dereference that value with the format string %s without verifying that it was valid. Now, insert an inline test that substitutes the string "(null)" for NULL pointers.
-
- 19 Feb, 2008 4 commits
-
-
tsmith@ramayana.hindu.god authored
Fixes the following bugs: - Bug #33349: possible race condition revolving around data dictionary and repartitioning Introduce retry/sleep logic as a workaround for a transient bug where ::open fails for partitioned tables randomly if we are using one file per table. - Bug #34053: normal users can enable innodb_monitor logging In CREATE TABLE and DROP TABLE check whether the table in question is one of the magic innodb_monitor tables and whether the user has enough rights to mess with it before doing anything else. - Bug #22868: 'Thread thrashing' with > 50 concurrent conns under an upd-intensive workloadw - Bug #29560: InnoDB >= 5.0.30 hangs on adaptive hash rw-lock 'waiting for an X-lock' This is a combination of changes that forward port the scalability fix applied to 5.0 through r1001. It reverts changes r149 and r122 (these were 5.1 specific changes made in lieu of scalability fix of 5.0) Then it applies r1001 to 5.0 which is the original scalability fix. Finally it applies r2082 which fixes an issue with the original fix. - Bug #30930: Add auxiliary function to retrieve THD::thread_id Add thd_get_thread_id() function. Also make check_global_access() function visible to InnoDB under INNODB_COMPATIBILITY_HOOKS #define.
-
kostja@dipika.(none) authored
-
kostja@dipika.(none) authored
does not send it to the client.
-
kostja@dipika.(none) authored
a SELECT doesn't cause ROLLBACK of statem". The idea of the fix is to ensure that we always commit the current statement at the end of dispatch_command(). In order to not issue redundant disc syncs, an optimization of the two-phase commit protocol is implemented to bypass the two phase commit if the transaction is read-only.
-
- 12 Feb, 2008 2 commits
-
-
anozdrin/alik@quad. authored
behave randomly with mysql_change_user. The problem was that global status variables were not updated in THD::check_user(), so thread statistics were lost after COM_CHANGE_USER. The fix is to update global status variables with the thread ones before preparing the thread for new user.
-
mkindahl@dl145h.mysql.com authored
tree with main.
-
- 09 Feb, 2008 1 commit
-
-
kostja@dipika.(none) authored
-
- 13 Dec, 2007 2 commits
-
-
mhansson/martin@linux-st28.site authored
subselects into account It is forbidden to use the SELECT INTO construction inside UNION statements unless on the last SELECT of the union. The parser records whether it has seen INTO or not when parsing a UNION statement. But if the INTO was legally used in an outer query, an error is thrown if UNION is seen in a subquery. Fixed in 5.0 by remembering the nesting level of INTO tokens and mitigate the error unless it collides with the UNION.
-
kostja@bodhi.(none) authored
last_insert_id introduced by the patch for Bug#12713 (part 1)
-
- 12 Dec, 2007 1 commit
-
-
kostja@bodhi.(none) authored
cause ROLLBACK of statement", part 1. Review fixes. Do not send OK/EOF packets to the client until we reached the end of the current statement. This is a consolidation, to keep the functionality that is shared by all SQL statements in one place in the server. Currently this functionality includes: - close_thread_tables() - log_slow_statement(). After this patch and the subsequent patch for Bug#12713, it shall also include: - ha_autocommit_or_rollback() - net_end_statement() - query_cache_end_of_result(). In future it may also include: - mysql_reset_thd_for_next_command().
-
- 20 Nov, 2007 2 commits
-
-
davi@endora.local authored
The problem is that DROP TABLE and other DDL statements failed to automatically close handlers associated with tables that were marked for reopen (FLUSH TABLES). The current implementation fails to properly discard handlers of dropped tables (that were marked for reopen) because it searches on the open handler tables list and using the current alias of the table being dropped. The problem is that it must not use the open handler tables list to search because the table might have been closed (marked for reopen) by a flush tables command and also it must not use the current table alias at all since multiple different aliases may be associated with a single table. This is specially visible when a user has two open handlers (using alias) of a same table and a flush tables command is issued before the table is dropped (see test case). Scanning the handler table list is also useless for dropping handlers associated with temporary tables, because temporary tables are not kept in the THD::handler_tables list. The solution is to simple scan the handlers hash table searching for, and deleting all handlers with matching table names if the reopen flag is not passed to the flush function, indicating that the handlers should be deleted. All matching handlers are deleted even if the associated the table is not open.
-
gshchepa/uchum@gleb.loc authored
8bit escape characters, termination and enclosed characters were silently ignored by SELECT INTO query, but LOAD DATA INFILE algorithm is 8bit-clean, so data was corrupted during encoding.
-
- 15 Nov, 2007 1 commit
-
-
anozdrin/alik@station. authored
different error code depending on platform. On Mac OS X, KILL statement issued to kill the current connection would return a different error code and message than on other platforms ('MySQL server has gone away' instead of 'Shutdown in progress'). The reason for this difference was that on Mac OS X we have macro SIGNAL_WITH_VIO_CLOSE defined. This macro forces KILL implementation to close the communication socket of the thread that is being killed. SIGNAL_WITH_VIO_CLOSE macro is defined on platforms where just sending a signal is not a reliable mechanism to interrupt the thread from sleeping on a blocking system call. In a nutshell, closing the socket is a hack to work around an operating system bug and awake the blocked thread no matter what. However, if the thread that is being killed is the same thread that issued KILL statement, closing the socket leads to a prematurely lost connection. At the same time it is not necessary to close the socket in this case, since the thread in question is not inside a blocking system call. The fix, therefore, is to not close the socket if the thread that is being killed is the same that issued KILL statement, even with defined SIGNAL_WITH_VIO_CLOSE.
-
- 10 Nov, 2007 1 commit
-
-
gshchepa/uchum@gleb.loc authored
After adding an index the <VARBINARY> IN (SELECT <BINARY> ...) clause returned a wrong result: the VARBINARY value was illegally padded with zero bytes to the length of the BINARY column for the index search. (<VARBINARY>, ...) IN (SELECT <BINARY>, ... ) clauses are affected too.
-
- 31 Oct, 2007 1 commit
-
-
kostja@bodhi.(none) authored
Add select_send::cleanup. Fix a compilation warning. Issues spotted while working on the fix for Bug#12713.
-
- 30 Oct, 2007 2 commits
-
-
kostja@bodhi.(none) authored
and convert it to a warning instead of direct manipulation with the thread error stack. Fix a bug in handler::print_erorr when a garbled message was printed for HA_ERR_NO_SUCH_TABLE. This is a pre-requisite patch for the fix for Bug#12713 Error in a stored function called from a SELECT doesn't cause ROLLBACK of statem
-
kostja@bodhi.(none) authored
in THD. In future the error may be stored elsewhere (not in net.report_error) and it's important to start using an opaque getter to simplify merges.
-
- 23 Oct, 2007 1 commit
-
-
gshchepa/uchum@gleb.loc authored
in the SELECT INTO OUTFILE clause starts with a special character (one of n, t, r, b, 0, Z or N) and ENCLOSED BY is empty, every occurrence of this character within a field value is duplicated. Duplication has been avoided. New warning message has been added: "First character of the FIELDS TERMINATED string is ambiguous; please use non-optional and non-empty FIELDS ENCLOSED BY".
-
- 19 Oct, 2007 2 commits
-
-
kostja@bodhi.(none) authored
Add comments.
-
anozdrin/alik@station. authored
There actually were several problems here: - WRITE-lock is required to load events from the mysql.event table, but in the read-only mode an ordinary user can not acquire it; - Security_context::master_access attribute was not properly initialized in Security_context::init(), which led to differences in behavior with and without debug configure options. - if the server failed to load events from mysql.event, it forgot to close the mysql.event table, that led to the coredump, described in the bug report. The patch is to fix all these problems: - Use the super-user to acquire WRITE-lock on the mysql.even table; - The WRITE-lock is acquired by the event scheduler in two cases: - on initial loading of events from the database; - when an event has been executed, so its attributes should be updated. Other cases when WRITE-lock is needed for the mysql.event table happen under the user account. So, nothing should be changed there for the read-only mode. The user is able to create/update/drop an event only if he is a super-user. - Initialize Security_context::master_access; - Close the mysql.event table in case something went wrong.
-
- 16 Oct, 2007 1 commit
-
-
cmiller@zippy.cornsilk.net authored
-
- 15 Oct, 2007 1 commit
-
-
kostja@bodhi.(none) authored
explicitly.
-
- 11 Oct, 2007 2 commits
-
-
monty@mysql.com/narttu.mysql.fi authored
- Reserver namespace and place in frm for TABLE_CHECKSUM and PAGE_CHECKSUM create options - Added syncing of directory when creating .frm files - Portability fixes - Added missing cast that could cause bugs - Code cleanups - Made some bit functions inline - Moved things out of myisam.h to my_handler.h to make them more accessable - Renamed some myisam variables and defines to make them more globaly usable (as they are used outside of MyISAM) - Fixed bugs in error conditions - Use compiler time asserts instead of run time - Fixed indentation HA_EXTRA_PREPARE_FOR_DELETE -> HA_EXTRA_PREPARE_FOR_DROP as the old name was wrong (Added a define for old value to ensure we don't break any old code) Added HA_EXTRA_PREPARE_FOR_RENAME as a signal for rename (before we used a DROP signal which is wrong) - Initialize error messages early to get better errors when mysqld or an engine fails to start - Fix windows bug that query_performance_frequency was not initialized if registry code failed - thread_stack -> my_thread_stack_size
-
anozdrin/alik@station. authored
mysql_change_user(). The problem was that THD::ull was not reset in THD::cleanup(). The fix is to reset it.
-
- 10 Oct, 2007 2 commits
-
-
tsmith@ramayana.hindu.god authored
Introduced in mark_transaction_to_rollback(), part of fix for bug 24989; fix is to check thd for NULL before using it.
-
anozdrin/alik@station. authored
of SQL_BIG_SELECTS. The bug was that SQL_BIG_SELECTS was not properly set in COM_CHANGE_USER. The fix is to update SQL_BIG_SELECTS properly.
-