1
0
mirror of https://github.com/MariaDB/server.git synced 2025-09-02 09:41:40 +03:00
Commit Graph

394 Commits

Author SHA1 Message Date
Marc Alff
41dc34d60b Bug#58052 Binary log IO not being accounted for properly
Before this fix, file io for the binary log file was not accounted properly,
and showed no io at all.

This bug was due to the following issues:

1) file io for the binlog was instrumented:
- sometime as "wait/io/file/sql/binlog"
- sometime as "wait/io/file/sql/MYSQL_LOG"
leading to inconsistent event_names.

2) the binlog file itself was using an IO_CACHE,
but the IO_CACHE implementation in mysys/mf_iocache.c was
not instrumented to make performance schema calls to record file io.

3) The "wait/io/file/sql/MYSQL_LOG" instrumentation was used
for several log files, such as:
- the binary log
- the slow log
- the query log
which caused file io in these different log files to be accounted
against the same instrument.
The instrumentation needs to have a finer grain and report io
in different event_names, because each file really serves a different purpose.

With this fix:
- the IO_CACHE implementation is now instrumented
- the "wait/io/file/sql/MYSQL_LOG" instrument has been removed
- binlog io is now always instrumented with "wait/io/file/sql/binlog"
- the slow log is instrumented with a new name, "wait/io/file/sql/slow_log"
- the query log is instrumented with a new name, "wait/io/file/sql/query_log"
2010-11-12 07:23:26 +01:00
Marc Alff
80589ada50 Bug#58052 Binary log IO not being accounted for properly
Before this fix, file io for the binary log file was not accounted properly,
and showed no io at all.

This bug was due to the following issues:

1) file io for the binlog was instrumented:
- sometime as "wait/io/file/sql/binlog"
- sometime as "wait/io/file/sql/MYSQL_LOG"
leading to inconsistent event_names.

2) the binlog file itself was using an IO_CACHE,
but the IO_CACHE implementation in mysys/mf_iocache.c was
not instrumented to make performance schema calls to record file io.

3) The "wait/io/file/sql/MYSQL_LOG" instrumentation was used
for several log files, such as:
- the binary log
- the slow log
- the query log
which caused file io in these different log files to be accounted
against the same instrument.
The instrumentation needs to have a finer grain and report io
in different event_names, because each file really serves a different purpose.

With this fix:
- the IO_CACHE implementation is now instrumented
- the "wait/io/file/sql/MYSQL_LOG" instrument has been removed
- binlog io is now always instrumented with "wait/io/file/sql/binlog"
- the slow log is instrumented with a new name, "wait/io/file/sql/slow_log"
- the query log is instrumented with a new name, "wait/io/file/sql/query_log"
2010-11-12 07:23:26 +01:00
unknown
7322e38827 MWL#136: Cross-engine consistency for START TRANSACTION WITH CONSISTENT SNAPSHOT
Make the binlog handlerton participate in START TRANSACTION WITH CONSISTENT
SNAPSHOT, recording the binlog position corresponding to the snapshot taken
in other MVCC storage engines.

Expose this consistent binlog position as the new status variables
binlog_trx_file and binlog_trx_position. This enables to get a fully
non-locking snapshot of the database (including binlog position for
slave provisioning), avoiding the need for FLUSH TABLES WITH READ LOCK.

Modify mysqldump to detect if the server supports this new feature, and
if so, avoid FLUSH TABLES WITH READ LOCK for --single-transaction
--master-data snapshot backups.
2010-11-07 22:37:43 +01:00
Alfranio Correia
3f5a9c7ea0 BUG#57275 binlog_cache_size affects trx- and stmt-cache and gets twice the expected memory
After the WL#2687, the binlog_cache_size and max_binlog_cache_size affect both the
stmt-cache and the trx-cache. This means that the resource used is twice the amount
expected/defined by the user.
      
The binlog_cache_use is incremented when the stmt-cache or the trx-cache is used
and binlog_cache_disk_use is incremented when the disk space from the stmt-cache or the
trx-cache is used. This behavior does not allow to distinguish which cache may be harming
performance due to the extra disk accesses and needs to have its in-memory cache
increased.
      
To fix the problem, we introduced two new options and status variables related to the
stmt-cache:
      
  Options:
      
    . binlog_stmt_cache_size
    . max_binlog_stmt_cache_size
      
    Status Variables:
      
    . binlog_stmt_cache_use
    . binlog_stmt_cache_disk_use

So there are

  . binlog_cache_size that defines the size of the transactional cache for
  updates to transactional engines for the binary log.

  . binlog_stmt_cache_size that defines the size of the statement cache for
  updates to non-transactional engines for the binary log.

  . max_binlog_cache_size that sets the total size of the transactional
  cache.

  . max_binlog_stmt_cache_size that sets the total size of the statement
  cache.

  . binlog_cache_use that identifies the number of transactions that used the
  temporary transactional binary log cache.

  . binlog_cache_disk_use that identifies the number of transactions that used
  the temporary transactional binary log cache but that exceeded the value of
  binlog_cache_size.

  . binlog_stmt_cache_use that identifies the number of statements that used the
  temporary non-transactional binary log cache.

  . binlog_stmt_cache_disk_use that identifies the number of statements that used
  the temporary non-transactional binary log cache but that exceeded the value of
  binlog_stmt_cache_size.

include/my_sys.h:
  Updated message on disk_writes' usage.
mysql-test/extra/binlog_tests/binlog_cache_stat.test:
  Updated the test case and added code to check the new status variables
  binlog_stmt_cache_use and binlog_stmt_cache_disk_use.
mysql-test/extra/rpl_tests/rpl_binlog_max_cache_size.test:
  Updated the test case to use the new system variables max_binlog_stmt_cache_size and binlog_stmt_cache_size.
mysql-test/r/mysqld--help-notwin.result:
  Updated the result file.
mysql-test/suite/binlog/r/binlog_mixed_cache_stat.result:
  Updated the result file.
mysql-test/suite/binlog/r/binlog_row_cache_stat.result:
  Updated the result file.
mysql-test/suite/binlog/r/binlog_stm_cache_stat.result:
  Updated the result file.
mysql-test/suite/rpl/r/rpl_mixed_binlog_max_cache_size.result:
  Update the result file.
mysql-test/suite/rpl/r/rpl_row_binlog_max_cache_size.result:
  Update the result file.
mysql-test/suite/rpl/r/rpl_stm_binlog_max_cache_size.result:
  Updated the result file.
mysql-test/suite/sys_vars/inc/binlog_stmt_cache_size_basic.inc:
  Added a test case to check the binlog_stmt_cache_size.
mysql-test/suite/sys_vars/r/binlog_stmt_cache_size_basic_32.result:
  Updated the result file.
mysql-test/suite/sys_vars/r/binlog_stmt_cache_size_basic_64.result:
  Updated the result file.
mysql-test/suite/sys_vars/r/max_binlog_stmt_cache_size_basic.result:
  Updated the result file.
mysql-test/suite/sys_vars/t/binlog_stmt_cache_size_basic_32.test:
  Added a test case to check the binlog_stmt_cache_size.
mysql-test/suite/sys_vars/t/binlog_stmt_cache_size_basic_64.test:
  Added a test case to check the binlog_stmt_cache_size.
mysql-test/suite/sys_vars/t/max_binlog_cache_size_func-master.opt:
  Removed because there is no test case max_binlog_cache_size_func.
mysql-test/suite/sys_vars/t/max_binlog_stmt_cache_size_basic.test:
  Added a test case to check the system variable max_binlog_stmt_cache_size.
sql/log.cc:
  There two main changes in here:
  
    . Changed the set_write_error() as an error message is set according
    to the type of the cache.
  
    . Created the function set_binlog_cache_info where references to the
    appropriate status and system variables are set and the server can
    smoothly compute statistics and set the maximum size for each cache.
sql/log.h:
  Changed the signature of the function in order to identify the error message
  to be printed out as there is a different error code for each type of cache.
sql/mysqld.cc:
  Added new status variables binlog_stmt_cache_use and binlog_stmt_cache_disk_use.
sql/mysqld.h:
  Added new system variables max_binlog_stmt_cache_size and binlog_stmt_cache_size.
sql/share/errmsg-utf8.txt:
  Added new error message related to the statement cache.
sql/sys_vars.cc:
  Added new system variables max_binlog_stmt_cache_size and binlog_stmt_cache_size.
2010-11-05 17:42:37 +00:00
Alfranio Correia
bf2c66d4a7 BUG#57275 binlog_cache_size affects trx- and stmt-cache and gets twice the expected memory
After the WL#2687, the binlog_cache_size and max_binlog_cache_size affect both the
stmt-cache and the trx-cache. This means that the resource used is twice the amount
expected/defined by the user.
      
The binlog_cache_use is incremented when the stmt-cache or the trx-cache is used
and binlog_cache_disk_use is incremented when the disk space from the stmt-cache or the
trx-cache is used. This behavior does not allow to distinguish which cache may be harming
performance due to the extra disk accesses and needs to have its in-memory cache
increased.
      
To fix the problem, we introduced two new options and status variables related to the
stmt-cache:
      
  Options:
      
    . binlog_stmt_cache_size
    . max_binlog_stmt_cache_size
      
    Status Variables:
      
    . binlog_stmt_cache_use
    . binlog_stmt_cache_disk_use

So there are

  . binlog_cache_size that defines the size of the transactional cache for
  updates to transactional engines for the binary log.

  . binlog_stmt_cache_size that defines the size of the statement cache for
  updates to non-transactional engines for the binary log.

  . max_binlog_cache_size that sets the total size of the transactional
  cache.

  . max_binlog_stmt_cache_size that sets the total size of the statement
  cache.

  . binlog_cache_use that identifies the number of transactions that used the
  temporary transactional binary log cache.

  . binlog_cache_disk_use that identifies the number of transactions that used
  the temporary transactional binary log cache but that exceeded the value of
  binlog_cache_size.

  . binlog_stmt_cache_use that identifies the number of statements that used the
  temporary non-transactional binary log cache.

  . binlog_stmt_cache_disk_use that identifies the number of statements that used
  the temporary non-transactional binary log cache but that exceeded the value of
  binlog_stmt_cache_size.
2010-11-05 17:42:37 +00:00
unknown
a786357be1 Minor whitespace/comment cleanup. 2010-11-01 16:01:25 +01:00
unknown
5614ebe7ed MWL#116: after-architecture-review code refactoring and cleanup.
Remove the extra class hierarchy with classes TC_LOG_queued, TC_LOG_unordered,
and TC_LOG_group_commit, folding the code into the TC_LOG_MMAP and
TC_LOG_BINLOG classes. In particular TC_LOG_BINLOG is greatly simplified by
this, unifying the code path for transactional and non-transactional
commit.

Remove unnecessary locking of LOCK_log in MYSQL_BIN_LOG::write() (backport
of same fix from mysql-5.5).
2010-10-29 13:58:47 +02:00
unknown
b91ad17cea MWL#116: Code simplifications for TC_LOG_MMAP.
Make TC_LOG_MMAP (and TC_LOG_DUMMY) derive directly from TC_LOG, avoiding the
inheritance hierarchy TC_LOG_queued->TC_LOG_unordered.

Put the wakeup facility for commit_ordered() calls into the THD class.

Some renaming to get better names.
2010-10-28 12:40:42 +02:00
unknown
aa23fe7dc1 MWL#116: Replace atomic queue with simple mutex locking for non-transactional binlog writes.
Also add missing destroy of pthread_cond.
2010-10-26 12:45:34 +02:00
unknown
45131a5b10 MWL#116: Efficient group commit: Fix assertion by moving init/deinit out of constructor in global static object. 2010-10-22 10:51:02 +02:00
unknown
498f10a2be Merge with latest MariaDB 5.1 2010-10-01 10:49:57 +02:00
unknown
0394cf2030 MWL#116: Efficient group commit for binary log
Preliminary commit for testing
2010-09-30 15:20:15 +02:00
Georgi Kodinov
6a0cfa23bd merge 2010-09-29 17:26:32 +03:00
Georgi Kodinov
216418e7b2 merge 2010-09-29 17:26:32 +03:00
Sergei Golubchik
a3d80d952d merge with 5.1 2010-09-11 20:43:48 +02:00
Alfranio Correia
eab1def49a BUG#55415 wait_for_update_bin_log enters a condition but does not leave
In sql/log.c, member function wait_for_update_bin_log, a condition is entered with
THD::enter_cond but is not exited. This might leave dangling references to the
mutex/condition in the per-thread information area.
      
To fix the problem, we call exit_cond to properly remove references to the mutex,
LOCK_log.
2010-09-06 18:18:44 +01:00
Alfranio Correia
95116114a4 BUG#55415 wait_for_update_bin_log enters a condition but does not leave
In sql/log.c, member function wait_for_update_bin_log, a condition is entered with
THD::enter_cond but is not exited. This might leave dangling references to the
mutex/condition in the per-thread information area.
      
To fix the problem, we call exit_cond to properly remove references to the mutex,
LOCK_log.
2010-09-06 18:18:44 +01:00
Georgi Kodinov
c95f7a9816 merge 2010-08-20 16:10:49 +03:00
Georgi Kodinov
bd62942ec1 merge 2010-08-20 16:10:49 +03:00
Georgi Kodinov
c9d20d6c08 merge 2010-08-20 14:22:46 +03:00
Georgi Kodinov
a54c3dd5c0 merge 2010-08-20 14:22:46 +03:00
Michael Widenius
d042146e5b Merge with MariaDB 5.1.49
Removed references to HA_END_SPACE_KEY (which has been 0 for a long time)
2010-08-05 22:56:11 +03:00
Alfranio Correia
f62e89fade BUG#55625 RBR breaks on failing 'CREATE TABLE'
A CREATE...SELECT that fails is written to the binary log if a non-transactional
statement is updated. If the logging format is ROW, the CREATE statement and the
changes are written to the binary log as distinct events and by consequence the
created table is not rolled back in the slave.

In this patch, we opted to let the slave goes out of sync by not writting to the
binary log the CREATE statement. We do this by simply reseting the binary log's
cache.

mysql-test/suite/rpl/r/rpl_drop.result:
  Added a test case.
mysql-test/suite/rpl/t/rpl_drop.test:
  Added a test case.
sql/log.cc:
  Introduced a function to clean up the cache.
sql/log.h:
  Introduced a function to clean up the cache.
sql/sql_insert.cc:
  Cleaned up the binary log cache if a CREATE...SELECT fails.
2010-08-02 20:48:56 +01:00
Alfranio Correia
1feee134fd BUG#55625 RBR breaks on failing 'CREATE TABLE'
A CREATE...SELECT that fails is written to the binary log if a non-transactional
statement is updated. If the logging format is ROW, the CREATE statement and the
changes are written to the binary log as distinct events and by consequence the
created table is not rolled back in the slave.

In this patch, we opted to let the slave goes out of sync by not writting to the
binary log the CREATE statement. We do this by simply reseting the binary log's
cache.
2010-08-02 20:48:56 +01:00
Davi Arnaut
bc4ba28cab WL#5498: Remove dead and unused source code
Remove unused variables.
2010-07-23 17:13:36 -03:00
Davi Arnaut
dd14fa18af WL#5498: Remove dead and unused source code
Remove unused variables.
2010-07-23 17:13:36 -03:00
Alfranio Correia
c9221a2a6f 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.
2010-06-30 16:25:13 +01:00
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.
2010-06-30 16:25:13 +01:00
Jon Olav Hauglid
142a162c66 manual merge from mysql-trunk-bugfixing
Conflicts:
Text conflict in mysql-test/r/archive.result
Contents conflict in mysql-test/r/innodb_bug38231.result
Text conflict in mysql-test/r/mdl_sync.result
Text conflict in mysql-test/suite/binlog/t/disabled.def
Text conflict in mysql-test/suite/rpl_ndb/r/rpl_ndb_binlog_format_errors.result
Text conflict in mysql-test/t/archive.test
Contents conflict in mysql-test/t/innodb_bug38231.test
Text conflict in mysql-test/t/mdl_sync.test
Text conflict in sql/sp_head.cc
Text conflict in sql/sql_show.cc
Text conflict in sql/table.cc
Text conflict in sql/table.h
2010-06-06 13:19:29 +02:00
Jon Olav Hauglid
1af11051bf manual merge from mysql-trunk-bugfixing
Conflicts:
Text conflict in mysql-test/r/archive.result
Contents conflict in mysql-test/r/innodb_bug38231.result
Text conflict in mysql-test/r/mdl_sync.result
Text conflict in mysql-test/suite/binlog/t/disabled.def
Text conflict in mysql-test/suite/rpl_ndb/r/rpl_ndb_binlog_format_errors.result
Text conflict in mysql-test/t/archive.test
Contents conflict in mysql-test/t/innodb_bug38231.test
Text conflict in mysql-test/t/mdl_sync.test
Text conflict in sql/sp_head.cc
Text conflict in sql/sql_show.cc
Text conflict in sql/table.cc
Text conflict in sql/table.h
2010-06-06 13:19:29 +02:00
Davi Arnaut
d108c80ee7 Fix type mismatch. Table names are represented as LEX_STRING
objects whose length is stored in a size_t type.
2010-05-27 18:28:24 -03:00
Davi Arnaut
a3d61b0bb2 Fix type mismatch. Table names are represented as LEX_STRING
objects whose length is stored in a size_t type.
2010-05-27 18:28:24 -03:00
Alfranio Correia
3f8bde448c BUG#53560 CREATE TEMP./DROP TEMP. are not binglogged correctly after a failed statement
This patch fixes two problems described as follows:

1 - If there is an on-going transaction and a temporary table is created or
dropped, any failed statement that follows the "create" or "drop commands"
triggers a rollback and by consequence the slave will go out sync because
the binary log will have a wrong sequence of events.

To fix the problem, we changed the expression that evaluates when the
cache should be flushed after either the rollback of a statment or
transaction.

2 - When a "CREATE TEMPORARY TABLE SELECT * FROM" was executed the
OPTION_KEEP_LOG was not set into the thd->options. For that reason, if
the transaction had updated only transactional engines and was rolled
back at the end (.e.g due to a deadlock) the changes were not written
to the binary log, including the creation of the temporary table.
      
To fix the problem, we have set the OPTION_KEEP_LOG into the thd->options
when a "CREATE TEMPORARY TABLE SELECT * FROM" is executed.

sql/log.cc:
  Reorganized the code based on the following functions:
  
  - bool ending_trans(const THD* thd, const bool all);
  - bool trans_has_updated_non_trans_table(const THD* thd);
  - bool trans_has_no_stmt_committed(const THD* thd, const bool all);
  - bool stmt_has_updated_non_trans_table(const THD* thd);
sql/log.h:
  Added functions to organize the code in log.cc.
sql/log_event.cc:
  Removed the OPTION_KEEP_LOG since it must be used only when
  creating and dropping temporary tables.
sql/log_event_old.cc:
  Removed the OPTION_KEEP_LOG since it must be used only when
  creating and dropping temporary tables.
sql/sql_parse.cc:
  When a "CREATE TEMPORARY TABLE SELECT * FROM" was executed the
  OPTION_KEEP_LOG was not set into the thd->options.
        
  To fix the problem, we have set the OPTION_KEEP_LOG into the
  thd->options when a "CREATE TEMPORARY TABLE SELECT * FROM"
  is executed.
2010-05-19 18:01:12 +01:00
Alfranio Correia
89850be0f5 BUG#53560 CREATE TEMP./DROP TEMP. are not binglogged correctly after a failed statement
This patch fixes two problems described as follows:

1 - If there is an on-going transaction and a temporary table is created or
dropped, any failed statement that follows the "create" or "drop commands"
triggers a rollback and by consequence the slave will go out sync because
the binary log will have a wrong sequence of events.

To fix the problem, we changed the expression that evaluates when the
cache should be flushed after either the rollback of a statment or
transaction.

2 - When a "CREATE TEMPORARY TABLE SELECT * FROM" was executed the
OPTION_KEEP_LOG was not set into the thd->options. For that reason, if
the transaction had updated only transactional engines and was rolled
back at the end (.e.g due to a deadlock) the changes were not written
to the binary log, including the creation of the temporary table.
      
To fix the problem, we have set the OPTION_KEEP_LOG into the thd->options
when a "CREATE TEMPORARY TABLE SELECT * FROM" is executed.
2010-05-19 18:01:12 +01:00
Alexey Kopytov
c7fbc8c67c Manual merge from mysql-5.1-bugteam to mysql-trunk-merge.
Text conflict in sql/log.cc
Text conflict in sql/log.h
Text conflict in sql/sql_class.cc
Text conflict in sql/sql_load.cc
2010-05-11 12:23:57 +04:00
Alexey Kopytov
e47ab5a604 Manual merge from mysql-5.1-bugteam to mysql-trunk-merge.
Text conflict in sql/log.cc
Text conflict in sql/log.h
Text conflict in sql/sql_class.cc
Text conflict in sql/sql_load.cc
2010-05-11 12:23:57 +04:00
He Zhenxing
df0b6707da Bug#53189 Table map version unused and can be removed
MYSQL_BIN_LOG m_table_map_version member and it's associated 
functions were not used in the logic of binlogging and replication,
this patch removed all related code.

sql/log.cc:
  removed unused m_table_map_version variable and functions
sql/log.h:
  removed unused m_table_map_version variable and functions
sql/log_event.h:
  Removed unused LOG_EVENT_UPDATE_TABLE_MAP_VERSION_F flag
sql/sql_class.cc:
  Removed unused LOG_EVENT_UPDATE_TABLE_MAP_VERSION_F flag
sql/sql_load.cc:
  Removed unused LOG_EVENT_UPDATE_TABLE_MAP_VERSION_F flag
sql/table.cc:
  removed unused table_map_version variable
sql/table.h:
  removed unused table_map_version variable
2010-05-08 11:25:33 +08:00
He Zhenxing
455f754e6b Bug#53189 Table map version unused and can be removed
MYSQL_BIN_LOG m_table_map_version member and it's associated 
functions were not used in the logic of binlogging and replication,
this patch removed all related code.
2010-05-08 11:25:33 +08:00
Alfranio Correia
20f5c421e7 BUG#51894 Replication failure with SBR on DROP TEMPORARY TABLE inside a
transaction
BUG#52616 Temp table prevents switch binlog format from STATEMENT to ROW

Before the WL#2687 and BUG#46364, every non-transactional change that happened
after a transactional change was written to trx-cache and flushed upon
committing the transaction. WL#2687 and BUG#46364 changed this behavior and
non-transactional changes are now written to the binary log upon committing
the statement.

A binary log event is identified as transactional or non-transactional through
a flag in the Log_event which is set taking into account the underlie storage
engine on what it is stems from. In the current bug, this flag was not being
set properly when the DROP TEMPORARY TABLE was executed.

However, while fixing this bug we figured out that changes to temporary tables
should be always written to the trx-cache if there is an on-going transaction.
Otherwise, binlog events in the reversed order would be produced.

Regarding concurrency, keeping changes to temporary tables in the trx-cache is
also safe as temporary tables are only visible to the owner connection.

In this patch, we classify the following statements as unsafe:
   1 - INSERT INTO t_myisam SELECT * FROM t_myisam_temp

   2 - INSERT INTO t_myisam_temp SELECT * FROM t_myisam

   3 - CREATE TEMPORARY TABLE t_myisam_temp SELECT * FROM t_myisam

On the other hand, the following statements are classified as safe:

   1 - INSERT INTO t_innodb SELECT * FROM t_myisam_temp

   2 - INSERT INTO t_myisam_temp SELECT * FROM t_innodb

The patch also guarantees that transactions that have a DROP TEMPORARY are
always written to the binary log regardless of the mode and the outcome:
commit or rollback. In particular, the DROP TEMPORARY is extended with the
IF EXISTS clause when the current statement logging format is set to row.

Finally, the patch allows to switch from STATEMENT to MIXED/ROW when there
are temporary tables but the contrary is not possible.

mysql-test/extra/rpl_tests/rpl_binlog_max_cache_size.test:
  Updated the test case because 
     CREATE TEMPORARY TABLE t_innodb_temp SELECT * FROM t_myisam is not unsafe.
mysql-test/extra/rpl_tests/rpl_implicit_commit_binlog.test:
  Updated the test case due to the new rules: changes to
  temporary tables are written to the binary log in the
  boundaries of a transaction if there is any.
mysql-test/extra/rpl_tests/rpl_innodb.test:
  Removed comments from the test case that became false after the patch.
mysql-test/extra/rpl_tests/rpl_loaddata.test:
  Suppressed warning messages due to the following cases:
  
     1 - INSERT INTO t_myisam SELECT * FROM t_myisam_temp
  
     2 - INSERT INTO t_myisam_temp SELECT * FROM t_myisam
mysql-test/include/ctype_utf8_table.inc:
  Suppressed warning messages due to the following cases:
  
     1 - INSERT INTO t_myisam SELECT * FROM t_myisam_temp
  
     2 - INSERT INTO t_myisam_temp SELECT * FROM t_myisam
mysql-test/r/ctype_cp932_binlog_stm.result:
  Updated the test case due to the new rules: changes to
  temporary tables are written to the binary log in the
  boundaries of a transaction if there is any.
mysql-test/suite/binlog/r/binlog_database.result:
  Updated the test case due to the new rules: changes to
  temporary tables are written to the binary log in the
  boundaries of a transaction if there is any.
mysql-test/suite/binlog/r/binlog_innodb_row.result:
  Updated the result file.
mysql-test/suite/binlog/r/binlog_multi_engine.result:
  Updated the unsafe message.
mysql-test/suite/binlog/r/binlog_row_binlog.result:
  Updated the test case due to the new rules: changes to
  temporary tables are written to the binary log in the
  boundaries of a transaction if there is any.
mysql-test/suite/binlog/r/binlog_row_drop_tmp_tbl.result:
  Updated the test case due to the new rules: changes to
  temporary tables are written to the binary log in the
  boundaries of a transaction if there is any.
mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result:
  Updated the test case due to the new rules: changes to
  temporary tables are written to the binary log in the
  boundaries of a transaction if there is any.
mysql-test/suite/binlog/r/binlog_stm_binlog.result:
  Updated the result file.
mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result:
  Updated the test case due to the new rules: changes to
  temporary tables are written to the binary log in the
  boundaries of a transaction if there is any.
mysql-test/suite/binlog/t/binlog_tmp_table.test:
  Suppressed warning messages due to the following cases:
  
     1 - INSERT INTO t_myisam SELECT * FROM t_myisam_temp
  
     2 - INSERT INTO t_myisam_temp SELECT * FROM t_myisam
mysql-test/suite/ndb/r/ndb_binlog_format.result:
  Updated the unsafe message.
mysql-test/suite/rpl/r/rpl_concurrency_error.result:
  Updated the unsafe message.
mysql-test/suite/rpl/r/rpl_mixed_binlog_max_cache_size.result:
  Updated the result file because 
     CREATE TEMPORARY TABLE t_innodb_temp SELECT * FROM t_myisam is not unsafe.
mysql-test/suite/rpl/r/rpl_mixed_implicit_commit_binlog.result:
  Updated the test case due to the new rules: changes to
  temporary tables are written to the binary log in the
  boundaries of a transaction if there is any.
mysql-test/suite/rpl/r/rpl_mixed_mixing_engines.result:
  Updated the test case due to the new rules: changes to
  temporary tables are written to the binary log in the
  boundaries of a transaction if there is any.
mysql-test/suite/rpl/r/rpl_mixed_row_innodb.result:
  Added some comments to ease the understanding of the result file.
mysql-test/suite/rpl/r/rpl_non_direct_mixed_mixing_engines.result:
  Updated the test case due to the new rules: changes to
  temporary tables are written to the binary log in the
  boundaries of a transaction if there is any.
mysql-test/suite/rpl/r/rpl_non_direct_row_mixing_engines.result:
  Updated the test case due to the new rules: changes to
  temporary tables are written to the binary log in the
  boundaries of a transaction if there is any.
mysql-test/suite/rpl/r/rpl_non_direct_stm_mixing_engines.result:
  Updated the test case due to the new rules: changes to
  temporary tables are written to the binary log in the
  boundaries of a transaction if there is any.
mysql-test/suite/rpl/r/rpl_row_drop.result:
  Updated the test case due to the new rules: changes to
  temporary tables are written to the binary log in the
  boundaries of a transaction if there is any.
mysql-test/suite/rpl/r/rpl_row_implicit_commit_binlog.result:
  Updated the test case due to the new rules: changes to
  temporary tables are written to the binary log in the
  boundaries of a transaction if there is any.
mysql-test/suite/rpl/r/rpl_row_mixing_engines.result:
  Updated the test case due to the new rules: changes to
  temporary tables are written to the binary log in the
  boundaries of a transaction if there is any.
mysql-test/suite/rpl/r/rpl_stm_binlog_max_cache_size.result:
  Updated the result file because 
     CREATE TEMPORARY TABLE t_innodb_temp SELECT * FROM t_myisam is not unsafe.
mysql-test/suite/rpl/r/rpl_stm_implicit_commit_binlog.result:
  Updated the test case due to the new rules: changes to
  temporary tables are written to the binary log in the
  boundaries of a transaction if there is any.
mysql-test/suite/rpl/r/rpl_stm_innodb.result:
  Added some comments to ease the understanding of the result file.
mysql-test/suite/rpl/r/rpl_stm_mixing_engines.result:
  Updated the test case due to the new rules: changes to
  temporary tables are written to the binary log in the
  boundaries of a transaction if there is any.
mysql-test/suite/rpl/r/rpl_stm_stop_middle_group.result:
  Updated the unsafe message.
mysql-test/suite/rpl/r/rpl_temp_temporary.result:
  Added a test case.
mysql-test/suite/rpl/t/rpl000013.test:
  Suppressed warning messages due to the following cases:
  
     1 - INSERT INTO t_myisam SELECT * FROM t_myisam_temp
  
     2 - INSERT INTO t_myisam_temp SELECT * FROM t_myisam
  
     3 - CREATE TEMPORARY TABLE t_myisam_temp SELECT * FROM t_myisam
mysql-test/suite/rpl/t/rpl_misc_functions.test:
  Suppressed warning messages.
mysql-test/suite/rpl/t/rpl_temp_table.test:
  Suppressed warning messages due to the following cases:
  
     1 - INSERT INTO t_myisam SELECT * FROM t_myisam_temp
  
     2 - INSERT INTO t_myisam_temp SELECT * FROM t_myisam
  
     3 - CREATE TEMPORARY TABLE t_myisam_temp SELECT * FROM t_myisam
mysql-test/suite/rpl/t/rpl_temp_temporary.test:
  Added a test case.
mysql-test/suite/rpl/t/rpl_temporary.test:
  Suppressed warning messages due to the following cases:
  
     1 - INSERT INTO t_myisam SELECT * FROM t_myisam_temp
  
     2 - INSERT INTO t_myisam_temp SELECT * FROM t_myisam
  
     3 - CREATE TEMPORARY TABLE t_myisam_temp SELECT * FROM t_myisam
mysql-test/suite/rpl_ndb/r/rpl_ndb_row_implicit_commit_binlog.result:
  Updated the test case due to the new rules: changes to
  temporary tables are written to the binary log in the
  boundaries of a transaction if there is any.
mysql-test/suite/rpl_ndb/r/rpl_truncate_7ndb.result:
  Updated the test case to remove references to positions
  in the binary log.
mysql-test/suite/rpl_ndb/t/rpl_truncate_7ndb.test:
  Updated the test case to remove references to positions
  in the binary log.
mysql-test/t/create_select_tmp.test:
  Suppressed warning messages due to the following cases:
  
     1 - INSERT INTO t_myisam SELECT * FROM t_myisam_temp
  
     2 - INSERT INTO t_myisam_temp SELECT * FROM t_myisam
  
     3 - CREATE TEMPORARY TABLE t_myisam_temp SELECT * FROM t_myisam
mysql-test/t/ctype_cp932_binlog_stm.test:
  Suppressed warning messages due to the following cases:
  
     1 - INSERT INTO t_myisam SELECT * FROM t_myisam_temp
  
     2 - INSERT INTO t_myisam_temp SELECT * FROM t_myisam
  
     3 - CREATE TEMPORARY TABLE t_myisam_temp SELECT * FROM t_myisam
mysql-test/t/mysqlbinlog.test:
  Suppressed warning messages due to the following cases:
  
     1 - INSERT INTO t_myisam SELECT * FROM t_myisam_temp
  
     2 - INSERT INTO t_myisam_temp SELECT * FROM t_myisam
  
     3 - CREATE TEMPORARY TABLE t_myisam_temp SELECT * FROM t_myisam
sql/log.cc:
  Improved the code by creating several functions to hide decision
  on type of engine changed, commit/abort, etc:  
  
  . stmt_has_updated_non_trans_table
  
  . trans_has_updated_non_trans_table
  
  . ending_trans
  
  Updated the binlog_rollback function and the use of the 
  OPTION_KEEP_LOG which indincates when a temporary table was
  either created or dropped and as such the command must be 
  logged if not in MIXED mode and even while rolling back the
  transaction.
sql/log.h:
  Improved the code by creating several functions to hide decision
  on type of engine changed, commit/abort, etc.
sql/log_event.cc:
  Removed the setting of the OPTION_KEEP_LOG as it is related to CREATE
  TEMPORARY and DROP TEMPORARY and not to the type of engine (i.e.
  transactional or non-transactional).
sql/log_event_old.cc:
  Removed the setting of the OPTION_KEEP_LOG as it is related to CREATE
  TEMPORARY and DROP TEMPORARY and not to the type of engine (i.e.
  transactional or non-transactional).
sql/share/errmsg-utf8.txt:
  Updated the unsafe message.
sql/sql_class.cc:
  Classifies the following statements as unsafe:
     1 - INSERT INTO t_myisam SELECT * FROM t_myisam_temp
  
     2 - INSERT INTO t_myisam_temp SELECT * FROM t_myisam
  
  On the other hand, the following statements are classified as safe:
  
     1 - INSERT INTO t_innodb SELECT * FROM t_myisam_temp
  
     2 - INSERT INTO t_myisam_temp SELECT * FROM t_innodb
sql/sql_class.h:
  It allows to switch from STATEMENT to MIXED/ROW when there are temporary
  tables but the contrary is not possible.
sql/sql_table.cc:
  Fixed the case that a DROP/DROP TEMPORARY that affects a temporary table in MIXED
  mode is written as a DROP TEMPORARY TABLE IF EXISTS because the table may not exist in the slave and due to the IF EXISTS token an error will never happen
  while processing the statement in the slave.
  
  Removed a function that was not being used.
2010-04-20 10:10:43 +01:00
Alfranio Correia
9ba731c299 BUG#51894 Replication failure with SBR on DROP TEMPORARY TABLE inside a
transaction
BUG#52616 Temp table prevents switch binlog format from STATEMENT to ROW

Before the WL#2687 and BUG#46364, every non-transactional change that happened
after a transactional change was written to trx-cache and flushed upon
committing the transaction. WL#2687 and BUG#46364 changed this behavior and
non-transactional changes are now written to the binary log upon committing
the statement.

A binary log event is identified as transactional or non-transactional through
a flag in the Log_event which is set taking into account the underlie storage
engine on what it is stems from. In the current bug, this flag was not being
set properly when the DROP TEMPORARY TABLE was executed.

However, while fixing this bug we figured out that changes to temporary tables
should be always written to the trx-cache if there is an on-going transaction.
Otherwise, binlog events in the reversed order would be produced.

Regarding concurrency, keeping changes to temporary tables in the trx-cache is
also safe as temporary tables are only visible to the owner connection.

In this patch, we classify the following statements as unsafe:
   1 - INSERT INTO t_myisam SELECT * FROM t_myisam_temp

   2 - INSERT INTO t_myisam_temp SELECT * FROM t_myisam

   3 - CREATE TEMPORARY TABLE t_myisam_temp SELECT * FROM t_myisam

On the other hand, the following statements are classified as safe:

   1 - INSERT INTO t_innodb SELECT * FROM t_myisam_temp

   2 - INSERT INTO t_myisam_temp SELECT * FROM t_innodb

The patch also guarantees that transactions that have a DROP TEMPORARY are
always written to the binary log regardless of the mode and the outcome:
commit or rollback. In particular, the DROP TEMPORARY is extended with the
IF EXISTS clause when the current statement logging format is set to row.

Finally, the patch allows to switch from STATEMENT to MIXED/ROW when there
are temporary tables but the contrary is not possible.
2010-04-20 10:10:43 +01:00
Mats Kindahl
23d8586dbf WL#5030: Split and remove mysql_priv.h
This patch:

- Moves all definitions from the mysql_priv.h file into
  header files for the component where the variable is
  defined
- Creates header files if the component lacks one
- Eliminates all include directives from mysql_priv.h
- Eliminates all circular include cycles
- Rename time.cc to sql_time.cc
- Rename mysql_priv.h to sql_priv.h
2010-03-31 16:05:33 +02:00
Mats Kindahl
e409d6f69c WL#5030: Split and remove mysql_priv.h
This patch:

- Moves all definitions from the mysql_priv.h file into
  header files for the component where the variable is
  defined
- Creates header files if the component lacks one
- Eliminates all include directives from mysql_priv.h
- Eliminates all circular include cycles
- Rename time.cc to sql_time.cc
- Rename mysql_priv.h to sql_priv.h
2010-03-31 16:05:33 +02:00
Sergei Golubchik
f09ca00e08 merged 2010-03-15 12:51:23 +01:00
Alexander Nozdrin
6f95733406 Manual merge of patch for Bug#46364 from mysql-next-mr-bugfixing.
Conflicts:
  - mysql-test/r/mysqld--help-win.result
  - sql/sys_vars.cc

Original revsion (in next-mr-bugfixing):
------------------------------------------------------------
revno: 2971 [merge]
revision-id: alfranio.correia@sun.com-20100121210527-rbuheu5rnsmcakh1
committer: Alfranio Correia <alfranio.correia@sun.com>
branch nick: mysql-next-mr-bugfixing
timestamp: Thu 2010-01-21 21:05:27 +0000
message:
  BUG#46364 MyISAM transbuffer problems (NTM problem)
        
  It is well-known that due to concurrency issues, a slave can become
  inconsistent when a transaction contains updates to both transaction and
  non-transactional tables.
                      
  In a nutshell, the current code-base tries to preserve causality among the
  statements by writing non-transactional statements to the txn-cache which
  is flushed upon commit. However, modifications done to non-transactional
  tables on behalf of a transaction become immediately visible to other
  connections but may not immediately get into the binary log and therefore
  consistency may be broken.
              
  In general, it is impossible to automatically detect causality/dependency
  among statements by just analyzing the statements sent to the server. This
  happen because dependency may be hidden in the application code and it is
  necessary to know a priori all the statements processed in the context of
  a transaction such as in a procedure. Moreover, even for the few cases that
  we could automatically address in the server, the computation effort
  required could make the approach infeasible.
              
  So, in this patch we introduce the option
        - "--binlog-direct-non-transactional-updates" that can be used to bypass
        the current behavior in order to write directly to binary log statements
        that change non-transactional tables.
  
  Besides, it is used to enable the WL#2687 which is disabled by default.
    ------------------------------------------------------------
    revno: 2970.1.1
    revision-id: alfranio.correia@sun.com-20100121131034-183r4qdyld7an5a0
    parent: alik@sun.com-20100121083914-r9rz2myto3tkdya0
    committer: Alfranio Correia <alfranio.correia@sun.com>
    branch nick: mysql-next-mr-bugfixing
    timestamp: Thu 2010-01-21 13:10:34 +0000
    message:
      BUG#46364 MyISAM transbuffer problems (NTM problem)
            
      It is well-known that due to concurrency issues, a slave can become
      inconsistent when a transaction contains updates to both transaction and
      non-transactional tables.
                          
      In a nutshell, the current code-base tries to preserve causality among the
      statements by writing non-transactional statements to the txn-cache which
      is flushed upon commit. However, modifications done to non-transactional
      tables on behalf of a transaction become immediately visible to other
      connections but may not immediately get into the binary log and therefore
      consistency may be broken.
                  
      In general, it is impossible to automatically detect causality/dependency
      among statements by just analyzing the statements sent to the server. This
      happen because dependency may be hidden in the application code and it is
      necessary to know a priori all the statements processed in the context of
      a transaction such as in a procedure. Moreover, even for the few cases that
      we could automatically address in the server, the computation effort
      required could make the approach infeasible.
                  
      So, in this patch we introduce the option
            - "--binlog-direct-non-transactional-updates" that can be used to bypass
            the current behavior in order to write directly to binary log statements
            that change non-transactional tables.
      
      Besides, it is used to enable the WL#2687 which is disabled by default.
2010-02-02 10:56:42 +03:00
Alexander Nozdrin
33e5e125f5 Manual merge of patch for Bug#46364 from mysql-next-mr-bugfixing.
Conflicts:
  - mysql-test/r/mysqld--help-win.result
  - sql/sys_vars.cc

Original revsion (in next-mr-bugfixing):
------------------------------------------------------------
revno: 2971 [merge]
revision-id: alfranio.correia@sun.com-20100121210527-rbuheu5rnsmcakh1
committer: Alfranio Correia <alfranio.correia@sun.com>
branch nick: mysql-next-mr-bugfixing
timestamp: Thu 2010-01-21 21:05:27 +0000
message:
  BUG#46364 MyISAM transbuffer problems (NTM problem)
        
  It is well-known that due to concurrency issues, a slave can become
  inconsistent when a transaction contains updates to both transaction and
  non-transactional tables.
                      
  In a nutshell, the current code-base tries to preserve causality among the
  statements by writing non-transactional statements to the txn-cache which
  is flushed upon commit. However, modifications done to non-transactional
  tables on behalf of a transaction become immediately visible to other
  connections but may not immediately get into the binary log and therefore
  consistency may be broken.
              
  In general, it is impossible to automatically detect causality/dependency
  among statements by just analyzing the statements sent to the server. This
  happen because dependency may be hidden in the application code and it is
  necessary to know a priori all the statements processed in the context of
  a transaction such as in a procedure. Moreover, even for the few cases that
  we could automatically address in the server, the computation effort
  required could make the approach infeasible.
              
  So, in this patch we introduce the option
        - "--binlog-direct-non-transactional-updates" that can be used to bypass
        the current behavior in order to write directly to binary log statements
        that change non-transactional tables.
  
  Besides, it is used to enable the WL#2687 which is disabled by default.
    ------------------------------------------------------------
    revno: 2970.1.1
    revision-id: alfranio.correia@sun.com-20100121131034-183r4qdyld7an5a0
    parent: alik@sun.com-20100121083914-r9rz2myto3tkdya0
    committer: Alfranio Correia <alfranio.correia@sun.com>
    branch nick: mysql-next-mr-bugfixing
    timestamp: Thu 2010-01-21 13:10:34 +0000
    message:
      BUG#46364 MyISAM transbuffer problems (NTM problem)
            
      It is well-known that due to concurrency issues, a slave can become
      inconsistent when a transaction contains updates to both transaction and
      non-transactional tables.
                          
      In a nutshell, the current code-base tries to preserve causality among the
      statements by writing non-transactional statements to the txn-cache which
      is flushed upon commit. However, modifications done to non-transactional
      tables on behalf of a transaction become immediately visible to other
      connections but may not immediately get into the binary log and therefore
      consistency may be broken.
                  
      In general, it is impossible to automatically detect causality/dependency
      among statements by just analyzing the statements sent to the server. This
      happen because dependency may be hidden in the application code and it is
      necessary to know a priori all the statements processed in the context of
      a transaction such as in a procedure. Moreover, even for the few cases that
      we could automatically address in the server, the computation effort
      required could make the approach infeasible.
                  
      So, in this patch we introduce the option
            - "--binlog-direct-non-transactional-updates" that can be used to bypass
            the current behavior in order to write directly to binary log statements
            that change non-transactional tables.
      
      Besides, it is used to enable the WL#2687 which is disabled by default.
2010-02-02 10:56:42 +03:00
Alfranio Correia
40949a3110 merge mysql-next-mr --> mysql-5.1-rpl-merge
Conflicts:
  Text conflict in sql/log.cc
  Text conflict in sql/slave.cc
  Text conflict in sql/sql_base.cc
2010-01-13 12:22:34 +00:00
Alfranio Correia
46d1689b7c merge mysql-next-mr --> mysql-5.1-rpl-merge
Conflicts:
  Text conflict in sql/log.cc
  Text conflict in sql/slave.cc
  Text conflict in sql/sql_base.cc
2010-01-13 12:22:34 +00:00
unknown
16e15e6952 Manual merge from next-mr. 2010-01-12 20:07:09 +08:00
b805e3d4d6 Manual merge from next-mr. 2010-01-12 20:07:09 +08:00
Alfranio Correia
5dcb0e447f merge mysql-5.1-rep+2-delivery1 --> mysql-5.1-rpl-merge
Conflicts:

Text conflict in .bzr-mysql/default.conf
Text conflict in mysql-test/extra/rpl_tests/rpl_loaddata.test
Text conflict in mysql-test/r/mysqlbinlog2.result
Text conflict in mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result
Text conflict in mysql-test/suite/binlog/r/binlog_unsafe.result
Text conflict in mysql-test/suite/rpl/r/rpl_insert_id.result
Text conflict in mysql-test/suite/rpl/r/rpl_loaddata.result
Text conflict in mysql-test/suite/rpl/r/rpl_stm_auto_increment_bug33029.result
Text conflict in mysql-test/suite/rpl/r/rpl_udf.result
Text conflict in mysql-test/suite/rpl/t/rpl_slow_query_log.test
Text conflict in sql/field.h
Text conflict in sql/log.cc
Text conflict in sql/log_event.cc
Text conflict in sql/log_event_old.cc
Text conflict in sql/mysql_priv.h
Text conflict in sql/share/errmsg.txt
Text conflict in sql/sp.cc
Text conflict in sql/sql_acl.cc
Text conflict in sql/sql_base.cc
Text conflict in sql/sql_class.h
Text conflict in sql/sql_db.cc
Text conflict in sql/sql_delete.cc
Text conflict in sql/sql_insert.cc
Text conflict in sql/sql_lex.cc
Text conflict in sql/sql_lex.h
Text conflict in sql/sql_load.cc
Text conflict in sql/sql_table.cc
Text conflict in sql/sql_update.cc
Text conflict in sql/sql_view.cc
Conflict adding files to storage/innobase.  Created directory.
Conflict because storage/innobase is not versioned, but has versioned children.  Versioned directory.
Conflict adding file storage/innobase.  Moved existing file to storage/innobase.moved.
Conflict adding files to storage/innobase/handler.  Created directory.
Conflict because storage/innobase/handler is not versioned, but has versioned children.  Versioned directory.
Contents conflict in storage/innobase/handler/ha_innodb.cc
2010-01-07 15:39:11 +00:00