1
0
mirror of https://github.com/MariaDB/server.git synced 2025-05-28 13:01:41 +03:00
unknown f07e4850d0 WWe now store the catalog in Query_log_event in binlog WITHOUT its end zero.
This saves one byte per Query_log_event on disk compared to 5.0.[0..3]. Compatibility problems with 5.0.x where x<4
are explained in the comments in log_event.cc. Putting back s/my_open(O_TRUNC)/(my_delete+my_create) change which had
been wiped away by somebody doing a wrong 4.1->5.0 merge (which happened just
before 5.0.3 :( ). Applying it to new events for LOAD DATA INFILE.
If slave fails in Execute_load_query_log_event::exec_event(),
don't delete the file (so that it's re-usable at next START SLAVE).
And (youpi!) fix for BUG#3247 "a partially completed LOAD DATA INFILE is not
executed at all on the slave" (storing an Execute_load_query_log_event
to binlog, with its error code, instead of Delete_file_log_event).


mysql-test/r/mix_innodb_myisam_binlog.result:
  we now use one less byte when storing the catalog in binlog so positions change
mysql-test/r/rpl_change_master.result:
  we now use one less byte when storing the catalog in binlog so positions change
mysql-test/r/rpl_deadlock.result:
  we now use one less byte when storing the catalog in binlog so positions change
mysql-test/r/rpl_error_ignored_table.result:
  we now use one less byte when storing the catalog in binlog so positions change
mysql-test/r/rpl_flush_log_loop.result:
  we now use one less byte when storing the catalog in binlog so positions change
mysql-test/r/rpl_loaddata.result:
  we now use one less byte when storing the catalog in binlog so positions change.
  Plus testing replication of LOAD DATA INFILE if duplicate key and non-transactional table.
mysql-test/r/rpl_log.result:
  we now use one less byte when storing the catalog in binlog so positions change
mysql-test/r/rpl_max_relay_size.result:
  we now use one less byte when storing the catalog in binlog so positions change
mysql-test/r/rpl_relayrotate.result:
  we now use one less byte when storing the catalog in binlog so positions change
mysql-test/r/rpl_replicate_do.result:
  we now use one less byte when storing the catalog in binlog so positions change
mysql-test/r/rpl_rotate_logs.result:
  we now use one less byte when storing the catalog in binlog so positions change
mysql-test/r/rpl_until.result:
  we now use one less byte when storing the catalog in binlog so positions change
mysql-test/t/mysqlbinlog.test:
  we now use one less byte when storing the catalog in binlog so positions change
mysql-test/t/mysqlbinlog2.test:
  we now use one less byte when storing the catalog in binlog so positions change
mysql-test/t/rpl_deadlock.test:
  we now use one less byte when storing the catalog in binlog so positions change
mysql-test/t/rpl_loaddata.test:
  we now use one less byte when storing the catalog in binlog so positions change.
  Plus testing replication of LOAD DATA INFILE if duplicate key and non-transactional table.
mysql-test/t/rpl_until.test:
  we now use one less byte when storing the catalog in binlog so positions change
sql/log_event.cc:
  a) We now store the catalog in Query_log_event in binlog WITHOUT its end zero.
  This saves one byte per Query_log_event on disk. Compatibility problems with 5.0.x where x<4
  are explained in the comments in this file.
  b) putting back s/my_open(O_TRUNC)/(my_delete+my_create) change which had
  been wiped away by somebody doing a wrong 4.1->5.0 merge (which happened just
  before 5.0.3 :( ). Applying it to new events for LOAD DATA INFILE.
  c) if slave fails in Execute_load_query_log_event::exec_event(),
  don't delete the file (so that it's re-usable at next START SLAVE).
sql/log_event.h:
  We now store the catalog in Query_log_event in binlog WITHOUT its end zero.
  This saves one byte per Query_log_event on disk. This new storage for
  the catalog is denoted by Q_CATALOG_NZ_CODE (couldn't re-use Q_CATALOG_CODE
  as 5.0.3 slaves of this 5.0.4 master would segfault because it would
  expect a 0 when there is none.
  Renaming get_open_mode() to get_create_or_append() (see log_event.cc)
sql/sql_load.cc:
  Fix for BUG#3247: if LOAD DATA INFILE fails but has permanently updated a table
  (i.e. has deleted/added/modified some rows in a non-transactional table),
  we must write an Execute_load_query_log_event to binlog (with the error code,
  as this class beautifully inherits from Query_log_event, it can store
  the error code - thanks Dmitri) and not a Delete_file_log_event (we use
  to write a Delete_file_log_event: no update happened on slave, bug).
2005-03-25 14:51:17 +01:00
..
2004-09-27 17:01:26 +02:00
2004-10-29 19:26:52 +03:00
2005-01-27 22:38:56 +01:00
2005-03-03 15:01:46 -08:00
2005-02-09 02:50:45 +04:00
2004-08-26 18:26:38 +03:00
2005-02-09 02:50:45 +04:00
2005-03-05 18:20:35 +04:00
2004-10-02 22:20:08 +03:00
2005-01-15 14:09:45 +02:00
2005-03-16 04:32:47 +03:00
2005-01-15 14:09:45 +02:00
2005-03-17 16:51:07 +03:00
2005-02-15 21:03:17 -08:00
2005-02-22 15:47:00 +02:00
2005-02-11 15:00:29 -08:00
2004-09-27 17:01:26 +02:00
2004-10-07 10:50:13 +03:00
2005-03-09 19:22:30 +01:00
2005-01-04 13:46:53 +02:00
2004-10-29 19:26:52 +03:00
2005-02-09 02:50:45 +04:00
2005-03-17 18:44:24 +03:00
2005-03-05 18:20:35 +04:00
2004-12-22 13:54:39 +02:00
2005-03-23 19:18:25 +01:00
2005-03-23 19:18:25 +01:00
2004-12-31 15:26:24 +01:00
2004-12-16 16:44:40 +02:00
2005-02-10 02:27:37 +02:00
2005-02-28 16:20:02 +02:00
2004-10-07 10:50:13 +03:00
2005-02-10 02:27:37 +02:00
2005-03-15 19:31:52 +04:00
2004-06-26 14:21:32 +02:00
2005-02-17 17:38:13 +00:00
2004-11-03 12:39:38 +02:00
2004-10-02 22:20:08 +03:00
2004-11-03 12:39:38 +02:00
2005-03-14 18:46:30 +01:00
2004-09-02 22:06:30 -07:00
2004-11-22 21:33:15 +01:00
2005-02-02 08:38:24 +02:00
2004-11-05 17:29:47 +02:00
2004-12-31 00:44:00 +02:00
2004-11-24 19:48:30 +02:00
2004-12-31 15:26:24 +01:00
2005-02-09 02:50:45 +04:00
2004-09-09 11:22:23 -05:00
2005-03-16 04:32:47 +03:00
2005-03-09 14:09:06 +01:00
2004-11-08 11:06:36 +01:00
2005-02-07 11:17:24 +01:00
2005-01-07 11:55:20 +01:00
2004-12-31 15:26:24 +01:00
2005-01-09 11:00:37 +01:00
2004-11-26 15:27:45 +00:00
2004-09-30 21:36:25 +00:00
2004-10-07 08:42:11 +00:00
2004-10-02 22:20:08 +03:00
2005-03-21 23:41:28 +02:00
2004-09-27 17:01:26 +02:00
2005-03-16 14:28:54 +02:00
2005-02-17 12:13:16 +01:00
2004-11-22 22:57:05 +01:00
2005-02-09 02:50:45 +04:00
2005-03-16 04:32:47 +03:00
2005-03-16 23:47:38 +01:00
2004-07-20 11:00:10 +02:00
2005-02-24 17:25:06 +01:00
2005-01-31 13:18:36 +00:00
2004-09-07 21:30:28 +02:00
2005-03-23 19:18:25 +01:00
2005-03-01 14:50:59 +02:00
2005-03-16 00:13:23 +00:00
2004-12-06 19:18:35 +02:00
2004-12-31 17:59:43 +01:00
2005-03-23 09:42:24 +01:00
2005-03-16 15:26:07 +02:00
2005-03-03 15:01:46 -08:00
2004-11-12 17:44:17 +02:00
2004-08-24 17:24:23 +02:00
2005-03-05 18:20:35 +04:00
2005-02-05 08:54:13 -08:00
2004-12-22 13:54:39 +02:00
2005-02-22 15:47:00 +02:00
2005-02-28 12:18:39 +02:00
2004-09-28 20:08:00 +03:00
2005-01-15 14:09:45 +02:00
2004-09-28 20:08:00 +03:00
2005-02-15 17:12:13 +02:00
2005-03-17 10:59:25 +04:00
2005-03-16 04:32:47 +03:00