mariadb

Commit Graph

Author	SHA1	Message	Date
Bjorn Munch	97a33d38ed	Backporting fix from trunk (revid 3381), original comment: Blind attempt to fix BUG 12881278 - MAIN.MYISAM TEST FAILS ON LINUX The printed text is truncated on char 63: "MySQL thread id 1236, OS thread handle 0x7ff187b96700, query id" still I do not understand how this truncation could have caused the main.myisam failure but anyway - the buffer needs to be increased.	15 years ago
Alexander Nozdrin	dca971de92	Cherry-picking patch for 12777649 from mysql-5.5 to mysql-5.5.16-release. Original revision: # revision-id: georgi.kodinov@oracle.com-20110812135004-3z3yjy7krf374clu # parent: georgi.kodinov@oracle.com-20110812112536-dmh9i67tm8pqvz1a # committer: Georgi Kodinov <Georgi.Kodinov@Oracle.com> # branch nick: B12777649-5.5 # timestamp: Fri 2011-08-12 16:50:04 +0300 # message: # Bug #12777649: "OS THREAD ID" REMOVED # # Pushed Calvin's patch.	15 years ago
Georgi Kodinov	8d4d67c7ed	Bug #12777649 : "OS THREAD ID" REMOVED Pushed Calvin's patch.	15 years ago
Sergey Glukhov	de3693a1cd	Bug#11766594 59736: SELECT DISTINCT.. INCORRECT RESULT WITH DETERMINISTIC FUNCTION IN WHERE C 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.	15 years ago
Tor Didriksen	f95192fb06	Bug#12756017 - PROFILING: SET_THD_PROC_INFO DOES NOT NEED TO CALL DIRNAME_LENGTH EACH TIME	15 years ago
Kent Boortz	e5ce023f57	Updated/added copyright headers	15 years ago
Dmitry Lenev	db114007eb	Fix for bug #12641342 - "61401: UPDATE PERFORMANCE DEGRADES GRADUALLY IF A TRIGGER EXISTS". This bug manifested itself in two ways: - Firstly execution of any data-changing statement which required prelocking (i.e. involved stored function or trigger) as part of transaction slowed down a bit all subsequent statements in this transaction. So performance in transaction which periodically involved such statements gradually degraded over time. - Secondly execution of any data-changing statement which required prelocking as part of transaction prevented concurrent FLUSH TABLES WITH READ LOCK from proceeding until the end of transaction instead of end of particular statement. The problem was caused by incorrect handling of metadata lock used in FTWRL implementation for statements requiring prelocked mode. Each statement which changes data acquires global IX lock with STATEMENT duration. This lock is supposed to block concurrent FTWRL from proceeding until the statement ends. When entering prelocked mode, durations of all metadata locks acquired so far were changed to EXPLICIT, to prevent substatements from releasing these locks. When prelocked mode was left, durations of metadata locks were changed to TRANSACTIONAL (with a few exceptions) so they can be properly released at the end of transaction. Unfortunately, this meant that the global IX lock blocking FTWRL with STATEMENT duration was moved to TRANSACTIONAL duration after execution of statement requiring prelocking. Since each subsequent statement that required prelocking and tried to acquire global IX lock with STATEMENT duration got a new instance of MDL_ticket, which was later moved to TRANSACTIONAL duration, this led to unwarranted growth of number of tickets with TRANSACITONAL duration in this connection's MDL_context. As result searching for other tickets in it became slow and acquisition of other metadata locks by this transaction started to hog CPU. Moreover, this also meant that after execution of statement requiring prelocking concurrent FTWRL was blocked until the end of transaction instead of end of statement. This patch solves this problem by not moving locks to EXPLICIT duration when thread enters prelocked mode (unless it is a real LOCK TABLES mode). This step turned out to be not really necessary as substatements don't try to release metadata locks. Consequently, the global IX lock blocking FTWRL keeps its STATEMENT duration and is properly released at the end of statement and the above issue goes away.	15 years ago
Mayank Prasad	55d3381cc7	Bug#11764633 : 57491: THD->MAIN_DA.IS_OK() ASSERT IN EMBEDDED Issue: While running embedded server, if client issues TEE command (\T foo/bar) and "foo/bar" directory doesn't exist, it is suppose to give error. But it was aborting. This was happening because wrong error handler was being called. Solution: Modified calls to correct error handler. In embedded server case, there are two error handler (client and server) which are supposed to be called based on which context code is in. If it is in client context, client error handler should be called otherwise server. Test case: Test case automation is not possible as current (following) code doesn't allow '\T' to be executed from command line (OR command read from a file): [client/mysql.cc] ... static int com_tee(String buffer __attribute__((unused)), char line __attribute__((unused))) { char file_name[FN_REFLEN], end, param; if (status.batch) << THIS IS TRUE WHILE EXECUTING FROM COMMAND LINE. return 0; ... So, not adding test case in GA. WIll add a test case in mysql-trunk after removing above code so that this could be properly tested before GA.	15 years ago
Mayank Prasad	359549beab	merge from 5.1 for bug#11764633	15 years ago
Guilhem Bichot	25221cccd2	Fix for BUG#11755168 '46895: test "outfile_loaddata" fails (reproducible)'. In sql_class.cc, 'row_count', of type 'ha_rows', was used as last argument for ER_TRUNCATED_WRONG_VALUE_FOR_FIELD which is "Incorrect %-.32s value: '%-.128s' for column '%.192s' at row %ld". So 'ha_rows' was used as 'long'. On SPARC32 Solaris builds, 'long' is 4 bytes and 'ha_rows' is 'longlong' i.e. 8 bytes. So the printf-like code was reading only the first 4 bytes. Because the CPU is big-endian, 1LL is 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x01 so the first four bytes yield 0. So the warning message had "row 0" instead of "row 1" in test outfile_loaddata.test: -Warning 1366 Incorrect string value: '\xE1\xE2\xF7' for column 'b' at row 1 +Warning 1366 Incorrect string value: '\xE1\xE2\xF7' for column 'b' at row 0 All error-messaging functions which internally invoke some printf-life function are potential candidate for such mistakes. One apparently easy way to catch such mistakes is to use ATTRIBUTE_FORMAT (from my_attribute.h). But this works only when call site has both: a) the format as a string literal b) the types of arguments. So: func(ER(ER_BLAH), 10); will silently not be checked, because ER(ER_BLAH) is not known at compile time (it is known at run-time, and depends on the chosen language). And func("%s", a va_list argument); has the same problem, as the real type of arguments is not known at this site at compile time (it's known in some caller). Moreover, func(ER(ER_BLAH)); though possibly correct (if ER(ER_BLAH) has no '%' markers), will not compile (gcc says "error: format not a string literal and no format arguments"). Consequences: 1) ATTRIBUTE_FORMAT is here added only to functions which in practice take "string literal" formats: "my_error_reporter" and "print_admin_msg". 2) it cannot be added to the other functions: my_error(), push_warning_printf(), Table_check_intact::report_error(), general_log_print(). To do a one-time check of functions listed in (2), the following "static code analysis" has been done: 1) replace my_error(ER_xxx, arguments for substitution in format) with the equivalent my_printf_error(ER_xxx,ER(ER_xxx), arguments for substitution in format), so that we have ER(ER_xxx) and the arguments in the same call site 2) add ATTRIBUTE_FORMAT to push_warning_printf(), Table_check_intact::report_error(), general_log_print() 3) replace ER(xxx) with the hard-coded English text found in errmsg.txt (like: ER(ER_UNKNOWN_ERROR) is replaced with "Unknown error"), so that a call site has the format as string literal 4) this way, ATTRIBUTE_FORMAT can effectively do its job 5) compile, fix errors detected by ATTRIBUTE_FORMAT 6) revert steps 1-2-3. The present patch has no compiler error when submitted again to the static code analysis above. It cannot catch all problems though: see Field::set_warning(), in which a call to push_warning_printf() has a variable error (thus, not replacable by a string literal); I checked set_warning() calls by hand though. See also WL 5883 for one proposal to avoid such bugs from appearing again in the future. The issues fixed in the patch are: a) mismatch in types (like 'int' passed to '%ld') b) more arguments passed than specified in the format. This patch resolves mismatches by changing the type/number of arguments, not by changing error messages of sql/share/errmsg.txt. The latter would be wrong, per the following old rule: errmsg.txt must be as stable as possible; no insertions or deletions of messages, no changes of type or number of printf-like format specifiers, are allowed, as long as the change impacts a message already released in a GA version. If this rule is not followed: - Connectors, which use error message numbers, will be confused (by insertions/deletions of messages) - using errmsg.sys of MySQL 5.1.n with mysqld of MySQL 5.1.(n+1) could produce wrong messages or crash; such usage can easily happen if installing 5.1.(n+1) while /etc/my.cnf still has --language=/path/to/5.1.n/xxx; or if copying mysqld from 5.1.(n+1) into a 5.1.n installation. When fixing b), I have verified that the superfluous arguments were not used in the format in the first 5.1 GA (5.1.30 'bteam@astra04-20081114162938-z8mctjp6st27uobm'). Had they been used, then passing them today, even if the message doesn't use them anymore, would have been necessary, as explained above.	15 years ago
Georgi Kodinov	4c5dfc00f7	Bug #11764517 : 57359: POSSIBLE TO CIRCUMVENT SECURE_FILE_PRIV USING '..' ON WINDOWS Backport of the fix to 5.0 (to be null-merged to 5.1). Moved the test into the main test suite. Made mysql-test-run.pl to not use symlinks for sdtdata as the symlinks are now properly recognized by secure_file_priv. Made sure the paths in load_file(), LOAD DATA and SELECT .. INTO OUTFILE that are checked against secure_file_priv in a correct way similarly to 5.1 by the extended is_secure_file_path() backport before the comparison. Added an extensive test with all the variants of upper/lower case, slash/backslash and case sensitivity. Added few comments to the code.	15 years ago
Mikael Ronstrom	8486212a24	Fixed missing change of thd_unlock_connection_data to thd_unlock_thread_count	15 years ago
Alexander Nozdrin	506ff594c8	A patch for Bug#11763166 (55847: SHOW WARNINGS returns empty result set when SQLEXCEPTION is active. The problem was in a hackish THD::no_warnings_for_error attribute. When it was set, an error was not written to Warning_info -- only Diagnostics_area state was changed. That means, Diagnostics_area might contain error state, which is not present in Warning_info. The user-visible problem was that in some cases SHOW WARNINGS returned empty result set (i.e. there were no warnings) while the previous SQL statement failed. According to the MySQL protocol errors must be presented in warning list. The main idea of this patch is to remove THD::no_warnings_for_error. There were few places where it was used: - sql_admin.cc, handling of REPAIR TABLE USE_FRM. - sql_show.cc, when calling fill_schema_table_from_frm(). - sql_show.cc, when calling fill_table(). The fix is to either use internal-error-handlers, or to use temporary Warning_info storing warnings, which might be ignored. This patch is needed to fix Bug 11763162 (55843).	15 years ago
Mikael Ronström	cec8c6e790	Changed name to better reflect function logic in accordance with WL#5788	15 years ago
Mikael Ronström	0db7bb2bfe	Use C++ manner for unused param instead of C manner	15 years ago
Marko Mäkelä	1a0dde9206	Bug #11766513 - 59641: Prepared XA transaction in system after hard crash causes future shutdown hang InnoDB would hang on shutdown if any XA transactions exist in the system in the PREPARED state. This has been masked by the fact that MySQL would roll back any PREPARED transaction on shutdown, in the spirit of Bug #12161 Xa recovery and client disconnection. [mysql-test-run] do_shutdown_server: Interpret --shutdown_server 0 as a request to kill the server immediately without initiating a shutdown procedure. xid_cache_insert(): Initialize XID_STATE::rm_error in order to avoid a bogus error message on XA ROLLBACK of a recovered PREPARED transaction. innobase_commit_by_xid(), innobase_rollback_by_xid(): Free the InnoDB transaction object after rolling back a PREPARED transaction. trx_get_trx_by_xid(): Only consider transactions whose trx->is_prepared flag is set. The MySQL layer seems to prevent attempts to roll back connected transactions that are in the PREPARED state from another connection, but it is better to play it safe. The is_prepared flag was introduced in the InnoDB Plugin. trx_n_prepared: A new counter, counting the number of InnoDB transactions in the PREPARED state. logs_empty_and_mark_files_at_shutdown(): On shutdown, allow trx_n_prepared transactions to exist in the system. trx_undo_free_prepared(), trx_free_prepared(): New functions, to free the memory objects of PREPARED transactions on shutdown. This is not needed in the built-in InnoDB, because it would collect all allocated memory on shutdown. The InnoDB Plugin needs this because of innodb_use_sys_malloc. trx_sys_close(): Invoke trx_free_prepared() on all remaining transactions.	15 years ago
Mikael Ronstrom	917da2749f	Further review fixes	15 years ago
Mikael Ronström	fef450b17f	More work on interfaces	15 years ago
Mikael Ronström	b04b333e25	Defined private interface to THD variables, first step to plugin API	15 years ago
Mikael Ronström	cb33511af6	Added setters to scheduler interface	15 years ago
Mikael Ronström	c89e1f8093	more fixes of scheduler interface changes	15 years ago
Tor Didriksen	6b0b53d65c	Bug #59273 show profile source doesn't show Source_function or truncates Source_file Fixed the 'show profile source' part of the bug. Leaving SHOW ENGINE INNODB MUTEX to a separate patch.	15 years ago
Mikael Ronstrom	4e4081bb40	BUG#59549, fix compiler error on Windows, step 2	15 years ago
Sergey Vojtovich	cb2e57c788	BUG#58948 - Valgrind warning in do_handle_one_connection() Fixed that proxy_user may be used uninitialized.	15 years ago
Davi Arnaut	487f9bb219	Bug#58136: Crash in vio_close at concurrent disconnect and KILL The problem is a race between a session closing its vio (i.e. after a COM_QUIT) at the same time it is being killed by another thread. This could trigger a assertion in vio_close() as the two threads could end up closing the same vio, at the same time. This could happen due to the implementation of SIGNAL_WITH_VIO_CLOSE, which closes the vio of the thread being killed. The solution is to serialize the close of the Vio under LOCK_thd_data, which protects THD data. No regression test is added as this is essentially a debug issue and the test case would be quite convoluted as we would need to synchronize a session that is being killed -- which is a bit difficult since debug sync points code does not synchronize killed sessions.	15 years ago
Alexander Barkov	fad763a81f	Bug#57306 SHOW PROCESSLIST does not display string literals well. Problem: Extended characters outside of ASCII range where not displayed properly in SHOW PROCESSLIST, because thd_info->query was always sent as system_character_set (utf8). This was wrong, because query buffer is never converted to utf8 - it is always have client character set. Fix: sending query buffer using query character set @ sql/sql_class.cc @ sql/sql_class.h Introducing a new class CSET_STRING, a LEX_STRING with character set. Adding set_query(&CSET_STRING) Adding reset_query(), to use instead of set_query(0, NULL). @ sql/event_data_objects.cc Using reset_query() @ sql/log_event.cc Using reset_query() Adding charset argument to set_query_and_id(). @ sql/slave.cc Using reset_query(). @ sql/sp_head.cc Changing backing up and restore code to use CSET_STRING. @ sql/sql_audit.h Using CSET_STRING. In the "else" branch it's OK not to use global_system_variables.character_set_client. &my_charset_latin1, which is set in constructor, is fine (verified with Sergey Vojtovich). @ sql/sql_insert.cc Using set_query() with proper character set: table_name is utf8. @ sql/sql_parse.cc Adding character set argument to set_query_and_id(). (This is the main point where thd->charset() is stored into thd->query_string.cs, for use in "SHOW PROCESSLIST".) Using reset_query(). @ sql/sql_prepare.cc Storing client character set into thd->query_string.cs. @ sql/sql_show.cc Using CSET_STRING to fetch and send charset-aware query information from threads. @ storage/myisam/ha_myisam.cc Using set_query() with proper character set: table_name is utf8. @ mysql-test/r/show_check.result @ mysql-test/t/show_check.test Adding tests	16 years ago
Jorgen Loland	4bfd212177	Bug#54812: assert in Diagnostics_area::set_ok_status during EXPLAIN Before the patch, send_eof() of some subclasses of select_result (e.g., select_send::send_eof()) could handle being called after an error had occured while others could not. The methods that were not well-behaved would trigger an ASSERT on debug builds. Release builds were not affected. Consider the following query as an example for how the ASSERT could be triggered: A user without execute privilege on f() does SELECT MAX(key1) INTO @dummy FROM t1 WHERE f() < 1; resulting in "ERROR 42000: execute command denied to user..." The server would end the query by calling send_eof(). The fact that the error had occured would make the ASSERT trigger. select_dumpvar::send_eof() was the offending method in the bug report, but the problem also applied to other subclasses of select_result. This patch uniforms send_eof() of all subclasses of select_result to handle being called after an error has occured.	16 years ago
Dmitry Lenev	378cdc58c1	Patch that refactors global read lock implementation and fixes bug #57006 "Deadlock between HANDLER and FLUSH TABLES WITH READ LOCK" and bug #54673 "It takes too long to get readlock for 'FLUSH TABLES WITH READ LOCK'". The first bug manifested itself as a deadlock which occurred when a connection, which had some table open through HANDLER statement, tried to update some data through DML statement while another connection tried to execute FLUSH TABLES WITH READ LOCK concurrently. What happened was that FTWRL in the second connection managed to perform first step of GRL acquisition and thus blocked all upcoming DML. After that it started to wait for table open through HANDLER statement to be flushed. When the first connection tried to execute DML it has started to wait for GRL/the second connection creating deadlock. The second bug manifested itself as starvation of FLUSH TABLES WITH READ LOCK statements in cases when there was a constant stream of concurrent DML statements (in two or more connections). This has happened because requests for protection against GRL which were acquired by DML statements were ignoring presence of pending GRL and thus the latter was starved. This patch solves both these problems by re-implementing GRL using metadata locks. Similar to the old implementation acquisition of GRL in new implementation is two-step. During the first step we block all concurrent DML and DDL statements by acquiring global S metadata lock (each DML and DDL statement acquires global IX lock for its duration). During the second step we block commits by acquiring global S lock in COMMIT namespace (commit code acquires global IX lock in this namespace). Note that unlike in old implementation acquisition of protection against GRL in DML and DDL is semi-automatic. We assume that any statement which should be blocked by GRL will either open and acquires write-lock on tables or acquires metadata locks on objects it is going to modify. For any such statement global IX metadata lock is automatically acquired for its duration. The first problem is solved because waits for GRL become visible to deadlock detector in metadata locking subsystem and thus deadlocks like one in the first bug become impossible. The second problem is solved because global S locks which are used for GRL implementation are given preference over IX locks which are acquired by concurrent DML (and we can switch to fair scheduling in future if needed). Important change: FTWRL/GRL no longer blocks DML and DDL on temporary tables. Before this patch behavior was not consistent in this respect: in some cases DML/DDL statements on temporary tables were blocked while in others they were not. Since the main use cases for FTWRL are various forms of backups and temporary tables are not preserved during backups we have opted for consistently allowing DML/DDL on temporary tables during FTWRL/GRL. Important change: This patch changes thread state names which are used when DML/DDL of FTWRL is waiting for global read lock. It is now either "Waiting for global read lock" or "Waiting for commit lock" depending on the stage on which FTWRL is. Incompatible change: To solve deadlock in events code which was exposed by this patch we have to replace LOCK_event_metadata mutex with metadata locks on events. As result we have to prohibit DDL on events under LOCK TABLES. This patch also adds extensive test coverage for interaction of DML/DDL and FTWRL. Performance of new and old global read lock implementations in sysbench tests were compared. There were no significant difference between new and old implementations.	16 years ago
	180e74bd49	Bug#27606 GRANT statement should be replicated with DEFINER information "Grantor" columns' data is lost when replicating mysql.tables_priv. Slave SQL thread used its default user ''@'' as the grantor of GRANT\|REVOKE statements executing on it. In this patch, current user is put in query log event for all GRANT and REVOKE statement, SQL thread uses the user in query log event as grantor.	16 years ago
Davi Arnaut	ae6801eb23	Bug#37780: Make KILL reliable (main.kill fails randomly) - A prerequisite cleanup patch for making KILL reliable. The test case main.kill did not work reliably. The following problems have been identified: 1. A kill signal could go lost if it came in, short before a thread went reading on the client connection. 2. A kill signal could go lost if it came in, short before a thread went waiting on a condition variable. These problems have been solved as follows. Please see also added code comments for more details. 1. There is no safe way to detect, when a thread enters the blocking state of a read(2) or recv(2) system call, where it can be interrupted by a signal. Hence it is not possible to wait for the right moment to send a kill signal. It has been decided, not to fix it in the code. Instead, the test case repeats the KILL statement until the connection terminates. 2. Before waiting on a condition variable, we register it together with a synchronizating mutex in THD::mysys_var. After this, we need to test THD::killed again. At some places we did only test it in a loop condition before the registration. When THD::killed had been set between this test and the registration, we entered waiting without noticing the killed flag. Additional checks ahve been introduced where required. In addition to the above, a re-write of the main.kill test case has been done. All sleeps have been replaced by Debug Sync Facility synchronization. A couple of sync points have been added to the server code. To avoid further problems, if the test case fails in spite of the fixes, the test case has been added to the "experimental" list for now. - Most of the work on this patch is authored by Ingo Struewing	16 years ago
Magne Mahre	24fc7ca4c8	Bug#39932 "create table fails if column for FK is in different case than in corr index". Server was unable to find existing or explicitly created supporting index for foreign key if corresponding statement clause used field names in case different than one used in key specification and created yet another supporting index. In cases when name of constraint (and thus name of generated index) was the same as name of existing/explicitly created index this led to duplicate key name error. The problem was that unlike all other code Key_part_spec::operator==() compared field names in case sensitive fashion. As result routines responsible for getting rid of redundant generated supporting indexes for foreign key were not working properly for versions of field names using different cases. (backported from mysql-trunk)	16 years ago
Alfranio Correia	c6d4915f3c	BUG#53452 Inconsistent behavior of binlog_direct_non_transactional_updates with temp table This patch introduces two key changes in the replication's behavior. Firstly, it reverts part of BUG#51894 which puts any update to temporary tables into the trx-cache. Now, updates to temporary tables are handled according to the type of their engines as a regular table. Secondly, an unsafe mixed statement, (i.e. a statement that access transactional table as well non-transactional or temporary table, and writes to any of them), are written into the trx-cache in order to minimize errors in the execution when the statement logging format is in use. Such changes has a direct impact on which statements are classified as unsafe statements and thus part of BUG#53259 is reverted.	16 years ago
Jimmy Yang	da24a208dd	Fix bug #53496 Use Lock_time in slow query log output for InnoDB row lock wait time. Including the InnoDB lock time in the exiting "Lock_time" output.	16 years ago
Alfranio Correia	bd3aa7eb78	BUG#50312 Warnings for unsafe sub-statement not returned to client After BUG#36649, warnings for sub-statements are cleared when a new sub-statement is started. This is problematic since it suppresses warnings for unsafe statements in some cases. It is important that we always give a warning to the client, because the user needs to know when there is a risk that the slave goes out of sync. We fixed the problem by generating warning messages for unsafe statements while returning from a stored procedure, function, trigger or while executing a top level statement. We also started checking unsafeness when both performance and log tables are used. This is necessary after the performance schema which does a distinction between performance and log tables.	16 years ago
Georgi Kodinov	881a76699e	WL#1054: Pluggable authentication support Merged the implementation to a new base tree.	16 years ago
Alexander Nozdrin	b2f8005094	Auto-merge from mysql-trunk-bugfixing. ****** This patch fixes the following bugs: - Bug#5889: Exit handler for a warning doesn't hide the warning in trigger - Bug#9857: Stored procedures: handler for sqlwarning ignored - Bug#23032: Handlers declared in a SP do not handle warnings generated in sub-SP - Bug#36185: Incorrect precedence for warning and exception handlers The problem was in the way warnings/errors during stored routine execution were handled. Prior to this patch the logic was as follows: - when a warning/an error happens: if we're executing a stored routine, and there is a handler for that warning/error, remember the handler, ignore the warning/error and continue execution. - after a stored routine instruction is executed: check for a remembered handler and activate one (if any). This logic caused several problems: - if one instruction generates several warnings (errors) it's impossible to choose the right handler -- a handler for the first generated condition was chosen and remembered for activation. - mess with handling conditions in scopes different from the current one. - not putting generated warnings/errors into Warning Info (Diagnostic Area) is against The Standard. The patch changes the logic as follows: - Diagnostic Area is cleared on the beginning of each statement that either is able to generate warnings, or is able to work with tables. - at the end of a stored routine instruction, Diagnostic Area is left intact. - Diagnostic Area is checked after each stored routine instruction. If an instruction generates several condition, it's now possible to take a look at all of them and determine an appropriate handler.	16 years ago
Alexander Nozdrin	8909586f16	Rename select_send::abort() to select_send::abort_result_set() to be more descriptive.	16 years ago
Konstantin Osipov	6d059673f7	Implement WL#5502 Remove dead 5.0 class Sensitive_cursor. Remove dead and unused code. Update to reflect the code review requests.	16 years ago
Konstantin Osipov	ec2c3bf2c1	A pre-requisite patch for the fix for Bug#52044. This patch also fixes Bug#55452 "SET PASSWORD is replicated twice in RBR mode". The goal of this patch is to remove the release of metadata locks from close_thread_tables(). This is necessary to not mistakenly release the locks in the course of a multi-step operation that involves multiple close_thread_tables() or close_tables_for_reopen(). On the same token, move statement commit outside close_thread_tables(). Other cleanups: Cleanup COM_FIELD_LIST. Don't call close_thread_tables() in COM_SHUTDOWN -- there are no open tables there that can be closed (we leave the locked tables mode in THD destructor, and this close_thread_tables() won't leave it anyway). Make open_and_lock_tables() and open_and_lock_tables_derived() call close_thread_tables() upon failure. Remove the calls to close_thread_tables() that are now unnecessary. Simplify the back off condition in Open_table_context. Streamline metadata lock handling in LOCK TABLES implementation. Add asserts to ensure correct life cycle of statement transaction in a session. Remove a piece of dead code that has also become redundant after the fix for Bug 37521.	16 years ago
Davi Arnaut	9fd9857e0b	WL#5498: Remove dead and unused source code Remove code that has been disabled for a long time.	16 years ago
Georgi Kodinov	16a7308825	Bug #53493 : add_to_status does not handle the longlong fields in STATUS_VAR bytes_received/bytes_sent are ulonglong so they cannot be handled by the ulong handling code in add_to_status/add_diff_to_status(). Fixed by adding code to handle these two variables in add_to_status()/add_diff_to_status() and making sure they are not a subject to the ulong handling code.	16 years ago
Davi Arnaut	a10ae35328	Bug#34043: Server loops excessively in _checkchunk() when safemalloc is enabled Essentially, the problem is that safemalloc is excruciatingly slow as it checks all allocated blocks for overrun at each memory management primitive, yielding a almost exponential slowdown for the memory management functions (malloc, realloc, free). The overrun check basically consists of verifying some bytes of a block for certain magic keys, which catches some simple forms of overrun. Another minor problem is violation of aliasing rules and that its own internal list of blocks is prone to corruption. Another issue with safemalloc is rather the maintenance cost as the tool has a significant impact on the server code. Given the magnitude of memory debuggers available nowadays, especially those that are provided with the platform malloc implementation, maintenance of a in-house and largely obsolete memory debugger becomes a burden that is not worth the effort due to its slowness and lack of support for detecting more common forms of heap corruption. Since there are third-party tools that can provide the same functionality at a lower or comparable performance cost, the solution is to simply remove safemalloc. Third-party tools can provide the same functionality at a lower or comparable performance cost. The removal of safemalloc also allows a simplification of the malloc wrappers, removing quite a bit of kludge: redefinition of my_malloc, my_free and the removal of the unused second argument of my_free. Since free() always check whether the supplied pointer is null, redudant checks are also removed. Also, this patch adds unit testing for my_malloc and moves my_realloc implementation into the same file as the other memory allocation primitives.	16 years ago
	42eecc539a	The following statements support the CURRENT_USER() where a user is needed. DROP USER RENAME USER CURRENT_USER() ... GRANT ... TO CURRENT_USER() REVOKE ... FROM CURRENT_USER() ALTER DEFINER = CURRENT_USER() EVENTbut, When these statements are binlogged, CURRENT_USER() just is binlogged as 'CURRENT_USER()', it is not expanded to the real user name. When slave executes the log event, 'CURRENT_USER()' is expand to the user of slave SQL thread, but SQL thread's user name always NULL. This breaks the replication. After this patch, session's user will be written into query log events if these statements call CURREN_USER() or 'ALTER EVENT' does not assign a definer.	16 years ago
Alfranio Correia	e662b51eef	BUG#53259 Unsafe statement binlogged in statement format w/MyIsam temp tables BUG#54872 MBR: replication failure caused by using tmp table inside transaction Changed criteria to classify a statement as unsafe in order to reduce the number of spurious warnings. So a statement is classified as unsafe when there is on-going transaction at any point of the execution if: 1. The mixed statement is about to update a transactional table and a non-transactional table. 2. The mixed statement is about to update a temporary transactional table and a non-transactional table. 3. The mixed statement is about to update a transactional table and read from a non-transactional table. 4. The mixed statement is about to update a temporary transactional table and read from a non-transactional table. 5. The mixed statement is about to update a non-transactional table and read from a transactional table when the isolation level is lower than repeatable read. After updating a transactional table if: 6. The mixed statement is about to update a non-transactional table and read from a temporary transactional table. 7. The mixed statement is about to update a non-transactional table and read from a temporary transactional table. 8. The mixed statement is about to update a non-transactionala table and read from a temporary non-transactional table. 9. The mixed statement is about to update a temporary non-transactional table and update a non-transactional table. 10. The mixed statement is about to update a temporary non-transactional table and read from a non-transactional table. 11. A statement is about to update a non-transactional table and the option variables.binlog_direct_non_trans_update is OFF. The reason for this is that locks acquired may not protected a concurrent transaction of interfering in the current execution and by consequence in the result. So the patch reduced the number of spurious unsafe warnings. Besides we fixed a regression caused by BUG#51894, which makes temporary tables to go into the trx-cache if there is an on-going transaction. In MIXED mode, the patch for BUG#51894 ignores that the trx-cache may have updates to temporary non-transactional tables that must be written to the binary log while rolling back the transaction. So we fix this problem by writing the content of the trx-cache to the binary log while rolling back a transaction if a non-transactional temporary table was updated and the binary logging format is MIXED.	16 years ago
Dmitry Shulga	48a74d7472	Fixed bug #51855 . Race condition in XA START. If several threads concurrently execute the statement XA START 'x', then mysqld server could crash.	16 years ago
Davi Arnaut	1b504ab0b1	Revert Bug#48321 due to build breakage and failing tests.	16 years ago
	899a1d694f	The following statements support the CURRENT_USER() where a user is needed. DROP USER RENAME USER CURRENT_USER() ... GRANT ... TO CURRENT_USER() REVOKE ... FROM CURRENT_USER() ALTER DEFINER = CURRENT_USER() EVENTbut, When these statements are binlogged, CURRENT_USER() just is binlogged as 'CURRENT_USER()', it is not expanded to the real user name. When slave executes the log event, 'CURRENT_USER()' is expand to the user of slave SQL thread, but SQL thread's user name always NULL. This breaks the replication. After this patch, session's user will be written into query log events if these statements call CURREN_USER() or 'ALTER EVENT' does not assign a definer.	16 years ago
Konstantin Osipov	b140456601	WL#5419 "LOCK_open scalability: make tdc_refresh_version an atomic counter" Split the large LOCK_open section in open_table(). Do not call open_table_from_share() under LOCK_open. Remove thd->version. This fixes Bug#50589 "Server hang on a query evaluated using a temporary table" Bug#51557 "LOCK_open and kernel_mutex are not happy together" Bug#49463 "LOCK_table and innodb are not nice when handler instances are created". This patch has effect on storage engines that rely on ha_open() PSEA method being called under LOCK_open. In particular: 1) NDB is broken and left unfixed. NDB relies on LOCK_open being kept as part of ha_open(), since it uses auto-discovery. While previously the NDB open code was race-prone, now it simply fails on asserts. 2) HEAP engine had a race in ha_heap::open() when a share for the same table could be added twice to the list of shares, or a dangling reference to a share stored in HEAP handler. This patch aims to address this problem by 'pinning' the newly created share in the internal HEAP engine share list until at least one handler instance is created using that share.	16 years ago
Mats Kindahl	b1dcf448ea	WL#5363: Thread Pool Service Interface In order to allow thread schedulers to be dynamically loaded, it is necessary to make the following changes to the server: - Two new service interfaces - Modifications to InnoDB to inform the thread scheduler of state changes. - Changes to the VIO subsystem for checking if data is available on a socket. - Elimination of remains of the old thread pool implementation. The two new service interfaces introduces are: my_thread_scheduler A service interface to register a thread scheduler. thd_wait A service interface to inform thread scheduler that the thread is about to start waiting. In addition, the patch adds code that: - Add a call to thd_wait for table locks in mysys thd_lock.c by introducing a set function that can be used to set a callback to be used when waiting on a lock and resuming from waiting. - Calling the mysys set function from the server to set the callbacks correctly.	16 years ago
Alfranio Correia	02fc237a2c	BUG#50479 DDL stmt on row-only/stmt-only tables generate spurious binlog_format errors In the fix of BUG#39934 in 5.1-rep+3, errors are generated when binlog_format=row and a statement modifies a table restricted to statement-logging (ER_BINLOG_ROW_MODE_AND_STMT_ENGINE); or if binlog_format=statement and a statement modifies a table restricted to row-logging (ER_BINLOG_STMT_MODE_AND_ROW_ENGINE). However, some DDL statements that lock tables (e.g. ALTER TABLE, CREATE INDEX and CREATE TRIGGER) were causing spurious errors, although no row might be inserted into the binary log. To fix the problem, we tagged statements that may generate rows into the binary log and thence the warning messages are only printed out when the appropriate conditions hold and rows might be changed.	16 years ago

1 2 3 4 5 ...

1255 Commits (d1eb81f6abc34ef0635ce6cb87f36d6ea3aedf52)