An error occurred fetching the project authors.
- 27 Nov, 2009 1 commit
-
-
Alfranio Correia authored
<tmp_tbl> with RBL When binlogging the statement, the server always handle the existing object as a table, even though it is a view. However a view is handled differently in other parts of the code thus leading the statement to crash in RBL if the view exists. This happens because the underlying tables for the view are not opened when we try to call store_create_info() on the view in order to build a CREATE TABLE statement. This patch will only address the crash problem, other binlogging problems related to CREATE TABLE IF NOT EXISTS LIKE when the existing object is a view will be solved by BUG 47442.
-
- 03 Nov, 2009 1 commit
-
-
Alfranio Correia authored
Non-transactional updates that take place inside a transaction present problems for logging because they are visible to other clients before the transaction is committed, and they are not rolled back even if the transaction is rolled back. It is not always possible to log correctly in statement format when both transactional and non-transactional tables are used in the same transaction. In the current patch, we ensure that such scenario is completely safe under the ROW and MIXED modes.
-
- 06 Oct, 2009 1 commit
-
-
Alfranio Correia authored
Let - T be a transactional table and N non-transactional table. - B be begin, C commit and R rollback. - N be a statement that accesses and changes only N-tables. - T be a statement that accesses and changes only T-tables. In RBR, changes to N-tables that happen early in a transaction are not immediately flushed upon committing a statement. This behavior may, however, break consistency in the presence of concurrency since changes done to N-tables become immediately visible to other connections. To fix this problem, we do the following: . B N N T C would log - B N C B N C B T C. . B N N T R would log - B N C B N C B T R. Note that we are not preserving history from the master as we are introducing a commit that never happened. However, this seems to be more acceptable than the possibility of breaking consistency in the presence of concurrency.
-
- 29 Sep, 2009 1 commit
-
-
Andrei Elkin authored
backporting from 6.0 code base to 5.1.
-
- 03 Dec, 2008 1 commit
-
-
Mats Kindahl authored
after rollback on master When starting a transaction with a statement containing changes to both transactional tables and non-transactional tables, the statement is considered as non-transactional and is therefore written directly to the binary log. This behaviour was present in 5.0, and has propagated to 5.1. If a trigger containing a change of a non-transactional table is added to a transactional table, any changes to the transactional table is "tainted" as non-transactional. This patch solves the problem by removing the existing "hack" that allows non-transactional statements appearing first in a transaction to be written directly to the binary log. Instead, anything inside a transaction is treaded as part of the transaction and not written to the binary log until the transaction is committed.
-
- 27 Nov, 2008 1 commit
-
-
Serge Kozlov authored
starting test rpl_row_create_table therefore the patch add the cleanup operation if DB with such name already exists.
-
- 08 Oct, 2008 1 commit
-
-
Mats Kindahl authored
The failure was caused by executing a CREATE-SELECT statement that creates a table in another database than the current one. In row-based logging, the CREATE statement was written to the binary log without the database, hence creating the table in the wrong database, causing the following inserts to fail since the table didn't exist in the given database. Fixed the bug by adding a parameter to store_create_info() that will make the function print the database name before the table name and used that in the calls that write the CREATE statement to the binary log. The database name is only printed if it is different than the currently selected database. The output of SHOW CREATE TABLE has not changed and is still printed without the database name.
-
- 19 Aug, 2008 1 commit
-
-
Mats Kindahl authored
The failure was caused by executing a CREATE-SELECT statement that creates a table in another database than the current one. In row-based logging, the CREATE statement was written to the binary log without the database, hence creating the table in the wrong database, causing the following inserts to fail since the table didn't exist in the given database. Fixed the bug by adding a parameter to store_create_info() that will make the function print the database name before the table name and used that in the calls that write the CREATE statement to the binary log. The database name is only printed if it is different than the currently selected database. The output of SHOW CREATE TABLE has not changed and is still printed without the database name.
-
- 08 Apr, 2008 1 commit
-
-
aelkin/andrei@mysql1000.(none) authored
Among two claimed artifacts the critical one is in that the Table map of a query following the failing with a duplicate key error CREATE-SELECT is skipped from instantionating (and thus binlogging). That leads to sending a "chopped" group of the data row-events without the table map head to the slave. The slave can not apply the only data row events. It's not easy to force the slave to react with an error in such a case (the second complaint on the bug report), because the lack of a table Rows_log_event::do_apply_event the data row event handler is a common situation which normally designates the event has to be filtered out basing on the repliation do/ingore rules decision. Fixed: table map creating and binlogging is restored via deploying the standard cleanup call in select_create::abort(). No error is reported if by chance the table map was not been binlogged. Leaving this out to resolve with considering how to combine the do/ingore rules with the situation when erronoulsy the Table_map is not written to binlog.
-
- 28 Mar, 2008 1 commit
-
-
mats@mats-laptop.(none) authored
The bug allow multiple executing transactions working with non-transactional to interfere with each others by interleaving the events of different trans- actions. Bug is fixed by writing non-transactional events to the transaction cache and flushing the cache to the binary log at statement commit. To mimic the behavior of normal statement-based replication, we flush the transaction cache in row- based mode when there is no committed statements in the transaction cache, which means we are committing the first one. This means that it will be written to the binary log as a "mini-transaction" with just the rows for the statement. Note that the changes here does not take effect when building the server with HAVE_TRANSACTIONS set to false, but it is not clear if this was possible before this patch either. For row-based logging, we also have that when AUTOCOMMIT=1, the code now always generates a BEGIN/COMMIT pair for single statements, or BEGIN/ROLLBACK pair in the case of non-transactional changes in a statement that was rolled back. Note that for the case where changes to a non-transactional table causes a rollback due to error, the statement will now be logged with a BEGIN/ROLLBACK pair, even though some changes has been committed to the non-transactional table.
-
- 14 Mar, 2008 2 commits
-
-
istruewing@stella.local authored
-
svoj@mysql.com/june.mysql.com authored
After merge fix.
-
- 14 Dec, 2007 1 commit
-
-
sven@riska.(none) authored
Now, every transaction (including autocommit transactions) starts with a BEGIN and ends with a COMMIT/ROLLBACK in the binlog. Added a test case, and updated lots of test case result files.
-
- 02 Aug, 2007 1 commit
-
-
cbell/Chuck@mysql_cab_desk. authored
This patch corrects a problem found during testing on Solaris. The code changes how length values are retrieved on big endian machines. The patch allows the rpl_extraColmaster tests to run on these machines.
-
- 31 Jul, 2007 1 commit
-
-
gkodinov/kgeorge@magare.gmz authored
-
- 29 Jul, 2007 1 commit
-
-
cbell/Chuck@mysql_cab_desk. authored
This patch adds the ability to store extra field metadata in the table map event. This data can include pack_length() or field_lenght() for fields such as CHAR or VARCHAR enabling developers to add code that can check for compatibilty between master and slave columns. More importantly, the extra field metadata can be used to store data from the master correctly should a VARCHAR field on the master be <= 255 bytes while the same field on the slave is > 255 bytes. The patch also includes the needed changes to unpack to ensure that data which is smaller on the master can be unpacked correctly on the slave. WL#3915 : (NDB) master's cols > slave Slave starts accepting and handling rows of master's tables which have more columns. The most important part of implementation is how to caclulate the amount of bytes to skip for unknown by slave column.
-
- 29 Jun, 2007 1 commit
-
-
msvensson@pilot.(none) authored
- Update test results for --binlog-format=row
-
- 27 Jun, 2007 1 commit
-
-
msvensson@pilot.(none) authored
- Update mysql-test-run.pl to collect tests from several suites - Group test into suites - Add suite.opt file
-
- 30 Mar, 2007 1 commit
-
-
mats@romeo.(none) authored
- Eliminating some compiler warnings
-
- 29 Mar, 2007 1 commit
-
-
mats@romeo.(none) authored
Adding an event that can be used to denote that an incident occured on the master. The event can be used to denote a gap in the replication stream, but can also be used to denote other incidents. In addition, the injector interface is extended with functions to generate an incident event. The function will also rotate the binary log after generating an incident event to get a fresh binary log.
-
- 07 Mar, 2007 1 commit
-
-
mats@romeo.(none) authored
Post-merge fixes.
-
- 12 Feb, 2007 1 commit
-
-
mats@romeo.(none) authored
does not work): Changing packed row format to only include null bits for those columns that are present in the row as well as writing BIT columns in a storage engine-independent format. The change in row format is incompatible with the previous format and a slave will not be able to read the new events.
-
- 21 Dec, 2006 1 commit
-
-
mats@romeo.(none) authored
from log): When row-based logging is used, the CREATE-SELECT is written as two parts: as a CREATE TABLE statement and as the rows for the table. For both transactional and non-transactional tables, the CREATE TABLE statement was written to the transaction cache, as were the rows, and on statement end, the entire transaction cache was written to the binary log if the table was non-transactional. For transactional tables, the events were kept in the transaction cache until end of transaction (or statement that were not part of a transaction). For the case when AUTOCOMMIT=0 and we are creating a transactional table using a create select, we would then keep the CREATE TABLE statement and the rows for the CREATE-SELECT, while executing the following statements. On a rollback, the transaction cache would then be cleared, which would also remove the CREATE TABLE statement. Hence no table would be created on the slave, while there is an empty table on the master. This relates to BUG#22865 where the table being created exists on the master, but not on the slave during insertion of rows into the newly created table. This occurs since the CREATE TABLE statement were still in the transaction cache until the statement finished executing, and possibly longer if the table was transactional. This patch changes the behaviour of the CREATE-SELECT statement by adding an implicit commit at the end of the statement when creating non-temporary tables. Hence, non-temporary tables will be written to the binary log on completion, and in the even of AUTOCOMMIT=0, a new transaction will be started. Temporary tables do not commit an ongoing transaction: neither as a pre- not a post-commit. The events for both transactional and non-transactional tables are saved in the transaction cache, and written to the binary log at end of the statement.
-
- 04 Jul, 2006 1 commit
-
-
cmiller@zippy.(none) authored
COMMITs -- the numbers collapse to fill the gaps.
-
- 20 Jun, 2006 1 commit
-
-
guilhem@mysql.com authored
though unneeded". It's indeed unneeded, as slave is only interested in permanent tables, and permanent tables don't depend on temporary tables when in row-based binlogging mode. And other CREATE TEMPORARY TABLE (referring no table or with LIKE) already don't write the CREATE to binlog in row-based mode.
-
- 31 May, 2006 1 commit
-
-
mats@mysql.com authored
Switched to writing out table maps for tables that are locked when the first row in a statement is seen.
-
- 06 Mar, 2006 1 commit
-
-
msvensson@neptunus.(none) authored
-
- 24 Feb, 2006 1 commit
-
-
mats@mysql.com authored
Adaptions to make it work with NDB.
-
- 16 Feb, 2006 1 commit
-
-
mats@mysql.com authored
Table maps are now written on aquiring locks to tables and released at the end of each logical statement.
-
- 13 Feb, 2006 1 commit
-
-
ingo@mysql.com authored
Fixes for row level logging.
-
- 22 Dec, 2005 1 commit
-
-
lars@mysql.com authored
This includes both code and test cases.
-