summaryrefslogtreecommitdiff
path: root/sql/slave.h
Commit message (Collapse)AuthorAgeFilesLines
* Backport of:Konstantin Osipov2009-11-231-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ------------------------------------------------------------- revno: 2877 committer: Davi Arnaut <Davi.Arnaut@Sun.COM> branch nick: 35164-6.0 timestamp: Wed 2008-10-15 19:53:18 -0300 message: Bug#35164: Large number of invalid pthread_attr_setschedparam calls Bug#37536: Thread scheduling causes performance degradation at low thread count Bug#12702: Long queries take 100% of CPU and freeze other applications under Windows The problem is that although having threads with different priorities yields marginal improvements [1] in some platforms [2], relying on some statically defined priorities (QUERY_PRIOR and WAIT_PRIOR) to play well (or to work at all) with different scheduling practices and disciplines is, at best, a shot in the dark as the meaning of priority values may change depending on the scheduling policy set for the process. Another problem is that increasing priorities can hurt other concurrent (running on the same hardware) applications (such as AMP) by causing starvation problems as MySQL threads will successively preempt lower priority processes. This can be evidenced by Bug#12702. The solution is to not change the threads priorities and rely on the system scheduler to perform its job. This also enables a system admin to increase or decrease the scheduling priority of the MySQL process, if intended. Furthermore, the internal wrappers and code for changing the priority of threads is being removed as they are now unused and ancient. 1. Due to unintentional side effects. On Solaris this could artificially help benchmarks as calling the priority changing syscall millions of times is more beneficial than the actual setting of the priority. 2. Where it actually works. It has never worked on Linux as the default scheduling policy SCHED_OTHER only accepts the static priority 0.
* manual merge: mysql-5.1-rep+2-delivery1 --> mysql-5.1-rpl-mergeLuis Soares2009-10-221-1/+12
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Conflicts ========= Text conflict in .bzr-mysql/default.conf Text conflict in libmysqld/CMakeLists.txt Text conflict in libmysqld/Makefile.am Text conflict in mysql-test/collections/default.experimental Text conflict in mysql-test/extra/rpl_tests/rpl_row_sp006.test Text conflict in mysql-test/suite/binlog/r/binlog_tmp_table.result Text conflict in mysql-test/suite/rpl/r/rpl_loaddata.result Text conflict in mysql-test/suite/rpl/r/rpl_loaddata_fatal.result Text conflict in mysql-test/suite/rpl/r/rpl_row_create_table.result Text conflict in mysql-test/suite/rpl/r/rpl_row_sp006_InnoDB.result Text conflict in mysql-test/suite/rpl/r/rpl_stm_log.result Text conflict in mysql-test/suite/rpl_ndb/r/rpl_ndb_circular_simplex.result Text conflict in mysql-test/suite/rpl_ndb/r/rpl_ndb_sp006.result Text conflict in mysql-test/t/mysqlbinlog.test Text conflict in sql/CMakeLists.txt Text conflict in sql/Makefile.am Text conflict in sql/log_event_old.cc Text conflict in sql/rpl_rli.cc Text conflict in sql/slave.cc Text conflict in sql/sql_binlog.cc Text conflict in sql/sql_lex.h 21 conflicts encountered. NOTE ==== mysql-5.1-rpl-merge has been made a mirror of mysql-next-mr: - "mysql-5.1-rpl-merge$ bzr pull ../mysql-next-mr" This is the first cset (merge/...) committed after pulling from mysql-next-mr.
| * merge from 5.1-rpl+2 repo to a local branch with HB and bug@27808 fixesAndrei Elkin2009-10-011-0/+1
| |\
| | * BUG#43075 rpl.rpl_sync fails sporadically on pushbuildAlfranio Correia2009-09-301-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | NOTE: Backporting the patch to next-mr. The slave was crashing while failing to execute the init_slave() function. The issue stems from two different reasons: 1 - A failure while allocating the master info structure generated a segfault due to a NULL pointer. 2 - A failure while recovering generated a segfault due to a non-initialized relay log file. In other words, the mi->init and rli->init were both set to true before executing the recovery process thus creating an inconsistent state as the relay log file was not initialized. To circumvent such problems, we refactored the recovery process which is now executed while initializing the relay log. It is ensured that the master info structure is created before accessing it and any error is propagated thus avoiding to set mi->init and rli->init to true when for instance the relay log is not initialized or the relay info is not flushed. The changes related to the refactory are described below: 1 - Removed call to init_recovery from init_slave. 2 - Changed the signature of the function init_recovery. 3 - Removed flushes. They are called while initializing the relay log and master info. 4 - Made sure that if the relay info is not flushed the mi-init and rli-init are not set to true. In this patch, we also replaced the exit(1) in the fault injection by DBUG_ABORT() to make it compliant with the code guidelines.
| * | WL#342 heartbeatAndrei Elkin2009-09-291-1/+11
| |/ | | | | | | backporting from 6.0 code base to 5.1.
* | Bug#46640: output from mysqlbinlog command in 5.1 breaks replication2009-10-141-2/+1
|/ | | | | | | | | | The BINLOG statement was sharing too much code with the slave SQL thread, introduced with the patch for Bug#32407. This caused statements to be logged with the wrong server_id, the id stored inside the events of the BINLOG statement rather than the id of the running server. Fix by rearranging code a bit so that only relevant parts of the code are executed by the BINLOG statement, and the server_id of the server executing the statements will not be overrided by the server_id stored in the 'format description BINLOG statement'.
* BUG#44581 Slave stops when transaction with non-transactional table gets ↵Alfranio Correia2009-07-061-1/+0
| | | | | | | | | | | | | | | | | | | | lock wait timeout In STMT and MIXED modes, a statement that changes both non-transactional and transactional tables must be written to the binary log whenever there are changes to non-transactional tables. This means that the statement gets into the binary log even when the changes to the transactional tables fail. In particular , in the presence of a failure such statement is annotated with the error number and wrapped in a begin/rollback. On the slave, while applying the statement, it is expected the same failure and the rollback prevents the transactional changes to be persisted. Unfortunately, statements that fail due to concurrency issues (e.g. deadlocks, timeouts) are logged in the same way causing the slave to stop as the statements are applied sequentially by the SQL Thread. To fix this bug, we automatically ignore concurrency failures on the slave. Specifically, the following failures are ignored: ER_LOCK_WAIT_TIMEOUT, ER_LOCK_DEADLOCK and ER_XA_RBDEADLOCK.
* Bug #38240 Crash in safe_mutex_lock () thr_mutex.c line 97 on rotate_relay_log Andrei Elkin2009-06-231-1/+2
| | | | | | | | | | | | The reason for the crash was rotate_relay_log (mi=0x0) did not verify the passed value of active_mi. There are more cases where active_mi is supposed to be non-zero e.g change_master(), stop_slave(), and it's reasonable to protect from a similar crash all of them with common fixes. Fixed with spliting end_slave() in slave threads release and slave data clean-up parts (a new close_active_mi()). The new function is invoked at the very end of close_connections() so that all users of active_mi are proven to have left.
* Bug#28234 - global/session scope - documentation vs implementationIngo Struewing2008-11-221-0/+1
| | | | | | | | | | | | | Several system variables did not behave like system variables should do. When trying to SET them or use them in SELECT, they were reported as "unknown system variable". But they appeared in SHOW VARIABLES. This has been fixed by removing the "fixed_vars" array of variables and integrating the variables into the normal system variables chain. All of these variables do now behave as read-only global-only variables. Trying to SET them tells they are read-only, trying to SELECT the session value tells they are global only. Selecting the global value works. It delivers the same value as SHOW VARIABLES.
* BUG#37426: RBR breaks for CHAR() UTF-8 fields > 85 charsMats Kindahl2008-06-301-1/+2
| | | | | | | | | | | | | | | | | | | | | | | In order to handle CHAR() fields, 8 bits were reserved for the size of the CHAR field. However, instead of denoting the number of characters in the field, field_length was used which denotes the number of bytes in the field. Since UTF-8 fields can have three bytes per character (and has been extended to have four bytes per character in 6.0), an extra two bits have been encoded in the field metadata work for fields of type Field_string (i.e., CHAR fields). Since the metadata word is filled, the extra bits have been encoded in the upper 4 bits of the real type (the most significant byte of the metadata word) by computing the bitwise xor of the extra two bits. Since the upper 4 bits of the real type always is 1111 for Field_string, this means that for fields of length <256, the encoding is identical to the encoding used in pre-5.1.26 servers, but for lengths of 256 or more, an unrecognized type is formed, causing an old slave (that does not handle lengths of 256 or more) to stop.
* BUG#33029 5.0 to 5.1 replication fails on dup key when insertinghezx@mail.hezx.com2008-03-141-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Merge riska.(none):/home/sven/bk/b34355-backslash_in_path_name_under_win/5.0-rplsven@riska.(none)2008-02-061-2/+2
|\ | | | | | | into riska.(none):/home/sven/bk/b34355-backslash_in_path_name_under_win/5.1-new-rpl
| * Bug #34305 show slave status handling segfaults when slave io is aboutaelkin/elkin@koti.dsl.inet.fi2008-02-051-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | to leave The artifact was caused by a flaw in concurrent accessing the slave's io thd by the io itself and a handling show slave status thread. Namely, show_master_info did not acquire mi->run_lock mutex that is specified for mi->io_thd member. Fixed with deploying the mutex locking and unlocking. The mutex is kept short time and without interleaving with mi->data_lock mutex. Todo: to report and fix an issue with sys_var_slave_skip_counter::{methods} seem to acquire incorrectly active_mi->rli.run_lock instead of the specified active_mi->rli.data_lock A test case is difficult to compose, so rpl_packet should continue serving as the indicator.
* | BUG#32407: Impossible to do point-in-time recovery from older binlogsven@riska.(none)2007-12-141-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Problem: it is unsafe to read base64-printed events without first reading the Format_description_log_event (FD). Currently, mysqlbinlog cannot print the FD. As a side effect, another bug has also been fixed: When mysqlbinlog --start-position=X was specified, no ROLLBACK was printed. I changed this, so that ROLLBACK is always printed. This patch does several things: - Format_description_log_event (FD) now print themselves in base64 format. - mysqlbinlog is now able to print FD events. It has three modes: --base64-output=auto Print row events in base64 output, and print FD event. The FD event is printed even if it is outside the range specified with --start-position, because it would not be safe to read row events otherwise. This is the default. --base64-output=always Like --base64-output=auto, but also print base64 output for query events. This is like the old --base64-output flag, which is also a shorthand for --base64-output=always --base64-output=never Never print base64 output, generate error if row events occur in binlog. This is useful to suppress the FD event in binlogs known not to contain row events (e.g., because BINLOG statement is unsafe, requires root privileges, is not SQL, etc) - the BINLOG statement now handles FD events correctly, by setting the thread's rli's relay log's description_event_for_exec to the loaded event. In fact, executing a BINLOG statement is almost the same as reading an event from a relay log. Before my patch, the code for this was separated (exec_relay_log_event in slave.cc executes events from the relay log, mysql_client_binlog_statement in sql_binlog.cc executes BINLOG statements). I needed to augment mysql_client_binlog_statement to do parts of what exec_relay_log_event does. Hence, I did a small refactoring and moved parts of exec_relay_log_event to a new function, which I named apply_event_and_update_pos. apply_event_and_update_pos is called both from exec_relay_log_event and from mysql_client_binlog_statement. - When a non-FD event is executed in a BINLOG statement, without previously executing a FD event in a BINLOG statement, it generates an error, because that's unsafe. I took a new error code for that: ER_NO_FORMAT_DESCRIPTION_EVENT_BEFORE_BINLOG_STATEMENTS. In order to get a decent error message containing the name of the event, I added the class method char* Log_event::get_type_str(Log_event_type type), which returns a string name for the given Log_event_type. This is just like the existing char* Log_event::get_type_str(), except it is a class method that takes the log event type as parameter. I also added PRE_GA_*_ROWS_LOG_EVENT to Log_event::get_type_str(), so that names of old rows event are properly printed. - When reading an event, I added a check that the event type is known by the current Format_description_log_event. Without this, it may crash on bad input (and I was struck by this several times). - I patched the following test cases, which all contain BINLOG statements for row events which must be preceded by BINLOG statements for FD events: - rpl_bug31076 While I was here, I fixed some small things in log_event.cc: - replaced hard-coded 4 by EVENT_TYPE_OFFSET in 3 places - replaced return by DBUG_VOID_RETURN in one place - The name of the logfile can be '-' to indicate stdin. Before my patch, the code just checked if the first character is '-'; now it does a full strcmp(). Probably, all arguments that begin with a - are already handled somewhere else as flags, but I still think it is better that the code reflects what it is supposed to do, with as little dependencies as possible on other parts of the code. If we one day implement that all command line arguments after -- are files (as most unix tools do), then we need this. I also fixed the following in slave.cc: - next_event() was declared twice, and queue_event was not static but should be static (not used outside the file).
* | Merge sita.local:/Users/tsmith/m/bk/maint/51-target22tsmith@sita.local2007-08-291-4/+0
|\ \ | | | | | | | | | into sita.local:/Users/tsmith/m/bk/maint/51
| * | BUG#29968 (rpl_ndb_circular.test and rpl_ndb_log.test fail):mats@kindahl-laptop.dnsalias.net2007-08-291-4/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Removing unguarded read of slave_running field from inside terminate_slave_threads(). This could cause premature exit in the event that the slave thread already were shutting down, but isn't finished yet. The fields slave_running, io_thd, and sql_thread are guarded by an associated run_lock. A read of these fields were not guarded inside terminate_slave_threads(), which caused an assertion to fire. The assertion was removed, and the code reorganized slightly.
* | | Merge weblab.(none):/home/marcsql/TREE/mysql-5.1-basemalff/marcsql@weblab.(none)2007-08-201-2/+10
|\ \ \ | | | | | | | | | | | | into weblab.(none):/home/marcsql/TREE/mysql-5.1-rt-merge
| * | | Add replication group (comments).kostja@bodhi.(none)2007-08-151-2/+10
| |/ /
* | | Renaming MASTER_INFO to Master_info in order to follow the codingmats@kindahl-laptop.dnsalias.net2007-08-161-16/+16
| | | | | | | | | | | | standards (and help Doxygen generating good documentation).
* | | Renaming RELAY_LOG_INFO and st_relay_log_info to follow coding standardsmats@kindahl-laptop.dnsalias.net2007-08-161-16/+15
|/ / | | | | | | (and be more friendly to Doxygen by removing unnecessary typedefs).
* | Merge mkindahl@bk-internal.mysql.com:/home/bk/mysql-5.1-rplmats@kindahl-laptop.dnsalias.net2007-06-091-3/+0
|\ \ | | | | | | | | | into kindahl-laptop.dnsalias.net:/home/bk/b24954-mysql-5.1-new-rpl
| * | BUG#24954 (Last_errno and Last_error not set after master_retry_count was ↵mats@kindahl-laptop.dnsalias.net2007-06-091-3/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | reached): Adding new fields Last_{IO,SQL}_Errno and Last_{IO,SQL}_Error to output of SHOW SLAVE STATUS to hold errors from I/O and SQL thread respectively. Old fields Last_Error and Last_Errno are aliases for Last_SQL_Error and Last_SQL_Errno respectively. Fields are added last to output of SHOW SLAVE STATUS to allow old applications to use the same positional arguments into the row, while allowing new application to benefit from the added information. In addition, some new error codes are added (especially for the I/O thread) to be able to provide sensible error message.
* | | WL#3817: Simplify string / memory area types and make things more consistent ↵monty@mysql.com/narttu.mysql.fi2007-05-101-8/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | (first part) The following type conversions was done: - Changed byte to uchar - Changed gptr to uchar* - Change my_string to char * - Change my_size_t to size_t - Change size_s to size_t Removed declaration of byte, gptr, my_string, my_size_t and size_s. Following function parameter changes was done: - All string functions in mysys/strings was changed to use size_t instead of uint for string lengths. - All read()/write() functions changed to use size_t (including vio). - All protocoll functions changed to use size_t instead of uint - Functions that used a pointer to a string length was changed to use size_t* - Changed malloc(), free() and related functions from using gptr to use void * as this requires fewer casts in the code and is more in line with how the standard functions work. - Added extra length argument to dirname_part() to return the length of the created string. - Changed (at least) following functions to take uchar* as argument: - db_dump() - my_net_write() - net_write_command() - net_store_data() - DBUG_DUMP() - decimal2bin() & bin2decimal() - Changed my_compress() and my_uncompress() to use size_t. Changed one argument to my_uncompress() from a pointer to a value as we only return one value (makes function easier to use). - Changed type of 'pack_data' argument to packfrm() to avoid casts. - Changed in readfrm() and writefrom(), ha_discover and handler::discover() the type for argument 'frmdata' to uchar** to avoid casts. - Changed most Field functions to use uchar* instead of char* (reduced a lot of casts). - Changed field->val_xxx(xxx, new_ptr) to take const pointers. Other changes: - Removed a lot of not needed casts - Added a few new cast required by other changes - Added some cast to my_multi_malloc() arguments for safety (as string lengths needs to be uint, not size_t). - Fixed all calls to hash-get-key functions to use size_t*. (Needed to be done explicitely as this conflict was often hided by casting the function to hash_get_key). - Changed some buffers to memory regions to uchar* to avoid casts. - Changed some string lengths from uint to size_t. - Changed field->ptr to be uchar* instead of char*. This allowed us to get rid of a lot of casts. - Some changes from true -> TRUE, false -> FALSE, unsigned char -> uchar - Include zlib.h in some files as we needed declaration of crc32() - Changed MY_FILE_ERROR to be (size_t) -1. - Changed many variables to hold the result of my_read() / my_write() to be size_t. This was needed to properly detect errors (which are returned as (size_t) -1). - Removed some very old VMS code - Changed packfrm()/unpackfrm() to not be depending on uint size (portability fix) - Removed windows specific code to restore cursor position as this causes slowdown on windows and we should not mix read() and pread() calls anyway as this is not thread safe. Updated function comment to reflect this. Changed function that depended on original behavior of my_pwrite() to itself restore the cursor position (one such case). - Added some missing checking of return value of malloc(). - Changed definition of MOD_PAD_CHAR_TO_FULL_LENGTH to avoid 'long' overflow. - Changed type of table_def::m_size from my_size_t to ulong to reflect that m_size is the number of elements in the array, not a string/memory length. - Moved THD::max_row_length() to table.cc (as it's not depending on THD). Inlined max_row_length_blob() into this function. - More function comments - Fixed some compiler warnings when compiled without partitions. - Removed setting of LEX_STRING() arguments in declaration (portability fix). - Some trivial indentation/variable name changes. - Some trivial code simplifications: - Replaced some calls to alloc_root + memcpy to use strmake_root()/strdup_root(). - Changed some calls from memdup() to strmake() (Safety fix) - Simpler loops in client-simple.c
* | | BUG#25688 (RBR: circular replication may cause STMT_END_F flags to bemats@romeo.(none)2007-04-121-2/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | skipped): By moving statement end actions from Rows_log_event::do_apply_event() to Rows_log_event::do_update_pos() they will always be executed, even if Rows_log_event::do_apply_event() is skipped because the event originated at the same server. This because Rows_log_event::do_update_pos() is always executed (unless Rows_log_event::do_apply_event() failed with an error, in which case the slave stops with an error anyway). Adding test case. Fixing logic to detect if inside a group. If a rotate event occured when an initial prefix of events for a statement, but for which the table did contain a key, last_event_start_time is set to zero, causing rotate to end the group but without unlocking any tables. This left a lock hanging around, which subsequently triggered an assertion when a second attempt was made to lock the same sequence of tables. In order to solve the above problem, a new flag was added to the relay log info structure that is used to indicate that the replication thread is currently executing a statement. Using this flag, the replication thread is in a group if it is either in a statement or inside a trans- action. The patch also eliminates some gratuitous header file inclusions that were not needed (and caused compile errors) and replaced them with forward definitions.
* | | Merge romeo.(none):/home/bkroot/mysql-5.1-new-rplmats@romeo.(none)2007-03-221-3/+3
|\ \ \ | | | | | | | | | | | | into romeo.(none):/home/bk/b23171-mysql-5.1-new-rpl
| * | | BUG#23171 (Illegal slave restart group position):mats@romeo.(none)2006-11-101-3/+3
| |/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | Second patch to fix skipping code. Moving relay and binary log position changing code from do_apply_event [old exec_event()] into do_update_pos() and doing other changes necessary to support that. Fixing a bug that can cause deadlock if rotating binary log when committing a changes to a transactional table that is not inside a transaction and cause a rotate log.
* | | Merge mysql.com:/nfsdisk1/lars/bkroot/mysql-5.1-new-rpllars/lthalmann@dl145h.mysql.com2007-02-241-0/+1
|\ \ \ | | | | | | | | | | | | into mysql.com:/nfsdisk1/lars/MERGE/mysql-5.1-merge
| * | | BUG#19033 (RBR: slave does not handle schema changes correctly):mats@romeo.(none)2007-02-231-9/+0
| | | | | | | | | | | | | | | | Post-merge fixes.
| * | | Merge romeo.(none):/home/bkroot/mysql-5.1-new-rplmats@romeo.(none)2007-02-231-0/+1
| |\ \ \ | | | | | | | | | | | | | | | into romeo.(none):/home/bk/b19033-mysql-5.1-new-rpl
| | * \ \ Merge gbichot3.local:/home/mysql_src/mysql-5.0-rpl-25507guilhem@gbichot3.local2007-02-151-0/+1
| | |\ \ \ | | | | |/ | | | |/| | | | | | into gbichot3.local:/home/mysql_src/mysql-5.1-rpl-25507
| | | * | Fix for BUG#24432guilhem@gbichot3.local2007-02-081-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | "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.
| * | | | Merge romeo.(none):/home/bkroot/mysql-5.1-new-rplmats@romeo.(none)2007-01-261-0/+9
| |\ \ \ \ | | |/ / / | |/| | | | | | | | into romeo.(none):/home/bk/b19033-mysql-5.1-new-rpl
| | * | | BUG#19033 (RBR: slave does not handle schema changes correctly):mats@romeo.(none)2007-01-261-0/+9
| | | |/ | | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since checking table compatibility before locking the table, there were potential that a table could be locked that did not have a definition that was compatible with the table on the slave. This patch adds a check just after the table was locked to ensure that the table is (still) compatible with the table on the slave.
* | | | After merge fixesmonty@mysql.com/narttu.mysql.fi2007-01-291-2/+0
|/ / / | | | | | | | | | | | | | | | | | | Removed a lot of compiler warnings Removed not used variables, functions and labels Initialize some variables that could be used unitialized (fatal bugs) %ll -> %l
* | | Merge mysql.com:/home/kent/bk/main/mysql-5.0kent@kent-amd64.(none)2006-12-231-2/+1
|\ \ \ | |/ / |/| / | |/ into mysql.com:/home/kent/bk/main/mysql-5.1
| * Many files:kent@mysql.com/kent-amd64.(none)2006-12-231-2/+1
| | | | | | | | Changed header to GPL version 2 only
| * Merge bk-internal:/home/bk/mysql-5.0-maintjimw@rama.(none)2006-09-281-1/+2
| |\ | | | | | | | | | into rama.(none):/home/jimw/my/mysql-5.0-clean
* | | Refactoring: Moved master info functionality into rpl_mi.cc to lars@mysql.com/black.(none)2006-10-311-114/+3
| | | | | | | | | | | | make code easier to maintain.
* | | Merge siva.hindu.god:/usr/home/tim/m/bk/g51tsmith/tim@siva.hindu.god2006-09-291-1/+2
|\ \ \ | | | | | | | | | | | | into siva.hindu.god:/usr/home/tim/m/bk/mrg/51
| * \ \ Merge rama.(none):/home/jimw/my/mysql-5.0-cleanjimw@rama.(none)2006-09-281-1/+2
| |\ \ \ | | | |/ | | |/| | | | | into rama.(none):/home/jimw/my/mysql-5.1-clean
| | * | Merge rama.(none):/home/jimw/my/mysql-4.1-cleanjimw@rama.(none)2006-09-281-1/+2
| | |\ \ | | | | | | | | | | | | | | | into rama.(none):/home/jimw/my/mysql-5.0-clean
| | | * | Bug #2717: include/my_global.h mis-defines __attribute__jimw@rama.(none)2006-08-171-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fix when __attribute__() is stubbed out, add ATTRIBUTE_FORMAT() for specifying __attribute__((format(...))) safely, make more use of the format attribute, and fix some of the warnings that this turns up (plus a bonus unrelated one).
* | | | | Merge mysql.com:/home/gluh/MySQL/Merge/5.0gluh@gluh.(none)2006-09-281-1/+1
|\ \ \ \ \ | |/ / / / |/| | | / | | |_|/ | |/| | into mysql.com:/home/gluh/MySQL/Merge/5.1
| * | | after merge fixgluh@mysql.com/gluh.(none)2006-09-271-1/+1
| |/ /
* | | Merge maint2.mysql.com:/data/localhome/tsmith/bk/mrg50/50tsmith@maint2.mysql.com2006-09-131-1/+1
|\ \ \ | |/ / | | | | | | into maint2.mysql.com:/data/localhome/tsmith/bk/mrg50/51
| * | after merge fixgluh@mysql.com/gluh.(none)2006-09-081-1/+1
| | |
| * | A fix for Bug#19022 "Memory bug when switching db during trigger execution". konstantin@mysql.com2006-06-281-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
| * | Fix yet another place that used uint32 instead of uint.konstantin@mysql.com2006-06-271-1/+1
| | |
| * | A fix and a test case forkonstantin@mysql.com2006-06-271-4/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* | | WL#3153 "Split logs". Recommit with post-review fixespetr@mysql.com2006-05-051-2/+2
| | |
View Lorry Controller Status