mariadb

Tree: eb1f21f8b6

Author	SHA1	Message	Date
msvensson@pilot.blaudden	696102a8c6	Bug#26837 Return value ignored for packet->append() call within Log_event::read_log_event - Improve error handling for "out of memory" problems when master is sending logs to slave. If memory allocation fails the log should now report error "memory allocation failed reading log event"	19 years ago
jani@ua141d10.elisa.omakaista.fi	5c542a4656	Fixed compiler warnings.	19 years ago
anozdrin/alik@booka.opbmk	c666e2f276	Polishing: use constants instead of magic numbers.	19 years ago
kostja@bodhi.local	86f02cd378	A fix for Bug#26750 "valgrind leak in sp_head" (and post-review fixes). The legend: on a replication slave, in case a trigger creation was filtered out because of application of replicate-do-table/ replicate-ignore-table rule, the parsed definition of a trigger was not cleaned up properly. LEX::sphead member was left around and leaked memory. Until the actual implementation of support of replicate-ignore-table rules for triggers by the patch for Bug 24478 it was never the case that "case SQLCOM_CREATE_TRIGGER" was not executed once a trigger was parsed, so the deletion of lex->sphead there worked and the memory did not leak. The fix: The real cause of the bug is that there is no 1 or 2 places where we can clean up the main LEX after parse. And the reason we can not have just one or two places where we clean up the LEX is asymmetric behaviour of MYSQLparse in case of success or error. One of the root causes of this behaviour is the code in Item::Item() constructor. There, a newly created item adds itself to THD::free_list - a single-linked list of Items used in a statement. Yuck. This code is unaware that we may have more than one statement active at a time, and always assumes that the free_list of the current statement is located in THD::free_list. One day we need to be able to explicitly allocate an item in a given Query_arena. Thus, when parsing a definition of a stored procedure, like CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END; we actually need to reset THD::mem_root, THD::free_list and THD::lex to parse the nested procedure statement (SELECT *). The actual reset and restore is implemented in semantic actions attached to sp_proc_stmt grammar rule. The problem is that in case of a parsing error inside a nested statement Bison generated parser would abort immediately, without executing the restore part of the semantic action. This would leave THD in an in-the-middle-of-parsing state. This is why we couldn't have had a single place where we clean up the LEX after MYSQLparse - in case of an error we needed to do a clean up immediately, in case of success a clean up could have been delayed. This left the door open for a memory leak. One of the following possibilities were considered when working on a fix: - patch the replication logic to do the clean up. Rejected as breaks module borders, replication code should not need to know the gory details of clean up procedure after CREATE TRIGGER. - wrap MYSQLparse with a function that would do a clean up. Rejected as ideally we should fix the problem when it happens, not adjust for it outside of the problematic code. - make sure MYSQLparse cleans up after itself by invoking the clean up functionality in the appropriate places before return. Implemented in this patch. - use %destructor rule for sp_proc_stmt to restore THD - cleaner than the prevoius approach, but rejected because needs a careful analysis of the side effects, and this patch is for 5.0, and long term we need to use the next alternative anyway - make sure that sp_proc_stmt doesn't juggle with THD - this is a large work that will affect many modules. Cleanup: move main_lex and main_mem_root from Statement to its only two descendants Prepared_statement and THD. This ensures that when a Statement instance was created for purposes of statement backup, we do not involve LEX constructor/destructor, which is fairly expensive. In order to track that the transformation produces equivalent functionality please check the respective constructors and destructors of Statement, Prepared_statement and THD - these members were used only there. This cleanup is unrelated to the patch.	19 years ago
bar@mysql.com	dd0c43d5fa	Bug#15126 character_set_database is not replicated (LOAD DATA INFILE need it) This patch fixes problem that LOAD DATA could use different character sets when loading files on master and on slave sides: - Adding replication of thd->variables.collation_database - Adding optional character set clause into LOAD DATA Note, the second way, with explicit CHARACTER SET clause should be the recommended way to load data using an alternative character set. The old way, using "SET @@character_set_database=xxx" should be gradually depricated.	19 years ago
guilhem@gbichot3.local	b3a03dada9	Fix for BUG#24432 "INSERT... ON DUPLICATE KEY UPDATE skips auto_increment values". When in an INSERT ON DUPLICATE KEY UPDATE, using an autoincrement column, we inserted some autogenerated values and also updated some rows, some autogenerated values were not used (for example, even if 10 was the largest autoinc value in the table at the start of the statement, 12 could be the first autogenerated value inserted by the statement, instead of 11). One autogenerated value was lost per updated row. Led to exhausting the range of the autoincrement column faster. Bug introduced by fix of BUG#20188; present since 5.0.24 and 5.1.12. This bug breaks replication from a pre-5.0.24 master. But the present bugfix, as it makes INSERT ON DUP KEY UPDATE behave like pre-5.0.24, breaks replication from a [5.0.24,5.0.34] master to a fixed (5.0.36) slave! To warn users against this when they upgrade their slave, as agreed with the support team, we add code for a fixed slave to detect that it is connected to a buggy master in a situation (INSERT ON DUP KEY UPDATE into autoinc column) likely to break replication, in which case it cannot replicate so stops and prints a message to the slave's error log and to SHOW SLAVE STATUS. For 5.0.36->[5.0.24,5.0.34] replication we cannot warn as master does not know the slave's version (but we always recommended to users to have slave at least as new as master). As agreed with support, I'll also ask for an alert to be put into the MySQL Network Monitoring and Advisory Service.	19 years ago
cbell/Chuck@suse.vabb.com	183c675980	BUG#22645 - LC_TIME_NAMES: Statement not replicated This patch is an additional code change to the get_str_len_and_pointer method in log_events.cc. This change is necessary to correct a problem encountered on 64-bit SUSE where the auto_increment_* variables were being overwritten. The change corrects a cast mismatch which caused the problem.	19 years ago
bar@mysql.com	2c039cccb6	log_event.cc: After merge fix	19 years ago
kent@mysql.com/kent-amd64.(none)	226a5c833f	Many files: Changed header to GPL version 2 only	19 years ago
monty@mysql.com/narttu.mysql.fi	88dd873de0	Fixed compiler warnings detected by option -Wshadow and -Wunused: - Removed not used variables and functions - Added #ifdef around code that is not used - Renamed variables and functions to avoid conflicts - Removed some not used arguments Fixed some class/struct warnings in ndb Added define IS_LONGDATA() to simplify code in libmysql.c I did run gcov on the changes and added 'purecov' comments on almost all lines that was not just variable name changes	19 years ago
bar@mysql.com/bar.intranet.mysql.r18.ru	cfdec2ca1e	After merge fix for bug N22645	19 years ago
bar@mysql.com/bar.intranet.mysql.r18.ru	b66f34bd19	Bug#22645 LC_TIME_NAMES: Statement not replicated Implementing event based replication of LC_TIME_NAMES for 5.0 (as a replacement of previously made ONE_SHOT replication)	19 years ago
bar@mysql.com/bar.intranet.mysql.r18.ru	a70028a855	Bug#20396 Bin Log does not get DELIMETER cmd - Recover StoredProc fails Problem: when loading mysqlbinlog dumps, CREATE PROCEDURE having semicolons in their bodies failed. Fix: Using safe delimiter "/!/;" to dump log entries.	19 years ago
monty@mysql.com/nosik.monty.fi	e825879800	Remove compiler warnings (Mostly in DBUG_PRINT() and unused arguments) Fixed bug in query cache when used with traceing (--with-debug) Fixed memory leak in mysqldump Removed warnings from mysqltest scripts (replaced -- with #)	19 years ago
aelkin/elkin@dsl-hkibras-fe30f900-107.dhcp.inet.fi	650a245568	bug#19402 SQL close to the size of the max_allowed_packet fails on the slave ver 5.0 and 5.1 refinement. adding to the MAX_SIZE_LOG_EVENT_STATUS estimation status vars and EXECUTE_LOAD_QUERY_EXTRA_HEADER_LEN	19 years ago
bar@mysql.com/bar.intranet.mysql.r18.ru	a5de478d51	Bug#23619 Incorrectly escaped multibyte characters in binary log break replication Problem: when embedding a character string with introducer with charset X into a SQL query which is generally in character set Y, the string constants were escaped according to their own character set (i.e.X), then after reading such a "mixed" query from binlog, the string constants were unescaped using character set of the query (i.e. Y), instead of X, which gave wrong results or even syntax errors with tricky charsets (e.g. sjis) Fix: when embedding a string constant of charset X into a query of charset Y, the string constant is now escaped according to character Y, instead of its own character set X.	19 years ago
kroki/tomash@moonlight.intranet	ee0cebf9a7	BUG#21726: Incorrect result with multiple invocations of LAST_INSERT_ID. Note: bug#21726 does not directly apply to 4.1, as it doesn't have stored procedures. However, 4.1 had some bugs that were fixed in 5.0 by the patch for bug#21726, and this patch is a backport of those fixes. Namely, in 4.1 it fixes: - LAST_INSERT_ID(expr) didn't return value of expr (4.1 specific). - LAST_INSERT_ID() could return the value generated by current statement if the call happens after the generation, like in CREATE TABLE t1 (i INT AUTO_INCREMENT PRIMARY KEY, j INT); INSERT INTO t1 VALUES (NULL, 0), (NULL, LAST_INSERT_ID()); - Redundant binary log LAST_INSERT_ID_EVENTs could be generated.	19 years ago
kroki/tomash@moonlight.intranet	5ea8adfae7	BUG#21726: Incorrect result with multiple invocations of LAST_INSERT_ID Non-upper-level INSERTs (the ones in the body of stored procedure, stored function, or trigger) into a table that have AUTO_INCREMENT column didn't affected the result of LAST_INSERT_ID() on this level. The problem was introduced with the fix of bug 6880, which in turn was introduced with the fix of bug 3117, where current insert_id value was remembered on the first call to LAST_INSERT_ID() (bug 3117) and was returned from that function until it was reset before the next _upper-level_ statement (bug 6880). The fix for bug#21726 brings back the behaviour of version 4.0, and implements the following: remember insert_id value at the beginning of the statement or expression (which at that point equals to the first insert_id value generated by the previous statement), and return that remembered value from LAST_INSERT_ID() or @@LAST_INSERT_ID. Thus, the value returned by LAST_INSERT_ID() is not affected by values generated by current statement, nor by LAST_INSERT_ID(expr) calls in this statement. Version 5.1 does not have this bug (it was fixed by WL 3146).	19 years ago
kaa@polly.local	b9811a6df1	Fixed the faulty merge	19 years ago
kaa@polly.local	397f0df9ad	Cset exclude: kaa@polly.local\|ChangeSet\|20060912122540\|09861 Cset exclude: kaa@polly.local\|ChangeSet\|20060908100829\|09983	19 years ago
kaa@polly.local	5df7611caa	Post-review fixes for bug #20924	19 years ago
konstantin@mysql.com	55d148c5c2	A fix for Bug#19022 "Memory bug when switching db during trigger execution". No test case as the bug is in an existing test case (rpl_trigger.test when it is run under valgrind). The warning was caused by memory corruption in replication slave: thd->db was pointing at a stack address that was previously used by sp_head::execute()::old_db. This happened because mysql_change_db behaved differently in replication slave and did not make a copy of the argument to assign to thd->db. The solution is to always free the old value of thd->db and allocate a new copy, regardless whether we're running in a replication slave or not.	20 years ago
konstantin@mysql.com	3cf181bb64	Fix compilation failures on Windows caused by the patch for Bug#17199. Fix a minor issue with Bug#16206 (bdb.test failed if the tree is compiled without blackhole).	20 years ago
konstantin@mysql.com	117b76a562	A fix and a test case for Bug#19022 "Memory bug when switching db during trigger execution" Bug#17199 "Problem when view calls function from another database." Bug#18444 "Fully qualified stored function names don't work correctly in SELECT statements" Documentation note: this patch introduces a change in behaviour of prepared statements. This patch adds a few new invariants with regard to how THD::db should be used. These invariants should be preserved in future: - one should never refer to THD::db by pointer and always make a deep copy (strmake, strdup) - one should never compare two databases by pointer, but use strncmp or my_strncasecmp - TABLE_LIST object table->db should be always initialized in the parser or by creator of the object. For prepared statements it means that if the current database is changed after a statement is prepared, the database that was current at prepare remains active. This also means that you can not prepare a statement that implicitly refers to the current database if the latter is not set. This is not documented, and therefore needs documentation. This is NOT a change in behavior for almost all SQL statements except: - ALTER TABLE t1 RENAME t2 - OPTIMIZE TABLE t1 - ANALYZE TABLE t1 - TRUNCATE TABLE t1 -- until this patch t1 or t2 could be evaluated at the first execution of prepared statement. CURRENT_DATABASE() still works OK and is evaluated at every execution of prepared statement. Note, that in stored routines this is not an issue as the default database is the database of the stored procedure and "use" statement is prohibited in stored routines. This patch makes obsolete the use of check_db_used (it was never used in the old code too) and all other places that check for table->db and assign it from THD::db if it's NULL, except the parser. How this patch was created: THD::{db,db_length} were replaced with a LEX_STRING, THD::db. All the places that refer to THD::{db,db_length} were manually checked and: - if the place uses thd->db by pointer, it was fixed to make a deep copy - if a place compared two db pointers, it was fixed to compare them by value (via strcmp/my_strcasecmp, whatever was approproate) Then this intermediate patch was used to write a smaller patch that does the same thing but without a rename. TODO in 5.1: - remove check_db_used - deploy THD::set_db in mysql_change_db See also comments to individual files.	20 years ago
cmiller@zippy.(none)	7b63337d31	Bug #16206 : Superfluous COMMIT event in binlog when updating BDB in autocommit mode This is a modification of serg's and guilhem's suggestion in the bug report, in that it also causes the transaction log to be written to disc.	20 years ago
mats@mysql.com	1d4ee057ee	BUG#18293 (Values in stored procedures written to binlog unescaped): Generating character set-independent quoting of strings for the binary log when executing statements from inside stored procedure.	20 years ago
aelkin@mysql.com	14ced05e55	BUG#16217 fix partly backported from 5.0. It is different in mysqlbinlog part. This changeset is assumed to stay in 4.1.	20 years ago
aelkin@mysql.com	dd2a44c497	BUG#16217 forced to introduce a separate mysql client command to adopt its internal charset to one associated with currently being handled query. To note such a query can come from interactive client either. There was a discussion within replication team and Monty who's suggestion won. It avoids straightforward parsing of all `set' queries that could affect client side character set. According to the idea, mysql client does not parse `set' queries but rather cares of `charset new_cs_name' command. This command is generated by mysqlbinlog in form of exclaiming comment (Lars' suggestion) so that enlightened clients like `mysql' knows what to do with it. Interactive human can switch between many multi-byte charsets during the session providing the command explicitly. To note that setting new internal mysql's charset does not trigger sending any `SET' sql statement to the server.	20 years ago
monty@mysql.com	6e22e29de6	Review fixes of new pushed code - Fixed tests - Optimized new code - Fixed some unlikely core dumps - Better bug fixes for: - #14397 - OPTIMIZE TABLE with an open HANDLER causes a crash - #14850 (ERROR 1062 when a quering a view using a Group By on a column that can be null	20 years ago
serg@serg.mylan	14f94dc0ca	many warnings (practically safe but annoying) corrected	20 years ago
knielsen@mysql.com	9248dfc840	Minor Win32 compile fixes for 4.1.16 release.	20 years ago
lars@mysql.com	9851469d12	Added explicit casts, since on i686, the fprintf function does not cast my_off_t correctly. Changed wrong printf to fprintf.	20 years ago
bell@sanja.is.com.ua	806f9e24ff	Inefficient usage of String::append() fixed. Bad examples of usage of a string with its length fixed. The incorrect length in the trigger file configuration descriptor fixed (BUG#14090). A hook for unknown keys added to the parser to support old .TRG files.	20 years ago
lars@mysql.com	4ccb1c6e36	mysqlbinlog --hexdump patch 4: Rename last_event_info to print_event_info to better reflect the new semantics	20 years ago
monty@mysql.com	4561014afa	Fixed compile errors on windows	20 years ago
guilhem@mysql.com	a6ceb59491	fixes after merge of 4.1.	20 years ago
lars@mysql.com	48457e0852	mysqlbin --hexdump patch 3	20 years ago
guilhem@mysql.com	4c1c9db823	Fix for BUG#13023: "SQL Thread is up but doesn't move forward". Details in slave.cc; in short we now record whenever the slave I/O thread ignores a master's event because of its server id, and use this info in the slave SQL thread to advance Exec_master_log_pos. Because if we do not, this variable stays at the position of the last executed event, i.e. the last non-ignored executed one, which may not be the last of the master's binlog (and so the slave looks behind the master though it's data-wise it's not).	20 years ago
monty@mysql.com	f5fdf3e87a	Reviewing new pushed code - CHAR() now returns binary string as default - CHAR(X65536+Y256+Z) is now equal to CHAR(X,Y,Z) independent of the character set for CHAR() - Test for both ETIMEDOUT and ETIME from pthread_cond_timedwait() (Some old systems returns ETIME and it's safer to test for both values than to try to write a wrapper for each old system) - Fixed new introduced bug in NOT BETWEEN X and X - Ensure we call commit_by_xid or rollback_by_xid for all engines, even if one engine has failed - Use octet2hex() for all conversion of string to hex - Simplify and optimize code	20 years ago
monty@mysql.com	78e828d32f	Review of code pushed since last 5.0 pull: Ensure that ccache is also used for C programs mysql: Ensure that 'delimiter' works the same way in batch mode as in normal mode mysqldump: Change to use ;; (instead of //) as a stored procedure/trigger delimiter Fixed test cases by adding missing DROP's and rename views to be of type 'v#' Removed MY_UNIX_PATH from fn_format() Removed current_db_used from TABLE_LIST Removed usage of 'current_thd' in Item_splocal Removed some compiler warnings A bit faster longlong2str code	20 years ago
lars@mysql.com	bf19d02b27	mysqlbinlog --hexdump additional patch 2 - Fixes related to Guilhems review - Special printing of event header	20 years ago
lars@mysql.com	d81d57d408	mysqlbinlog --hexdump augments each log entry with byte information	20 years ago
lars@mysql.com	9dd14fc381	BUG#12542: Added comments	21 years ago
SergeyV@selena.	3fdd500288	Fixes bug #11815 . Convert file path to UNIX format to build correct query string while replicating LOAD DATA INFILE statement.	21 years ago
lars@mysql.com	f34398ba65	BUG#12532: Fix for the case when my_malloc is macro	21 years ago
lars@mysql.com	f98f46c471	BUG#12532: Fixes after review	21 years ago
elliot@mysql.com	d9efe655ed	Bug#11338 Fixes from review (identical functionality).	21 years ago
lars@mysql.com	c79ba8e346	BUG#12532: Added more memory in malloc for slave query cache	21 years ago
monty@mishka.local	7e83d09ce7	Simple fixes during review of new code	21 years ago
elliot@mysql.com	22be12ab86	BUG#11567 Fixed binlog tests on windows.	21 years ago

1 2 3 4 5 ...

451 Commits (eb1f21f8b656e858cfef3daa72d9a5bee7951ce2)