MDEV-4506: Parallel replication. .result file updates + a few comment updates.

This commit is contained in:
unknown 2013-09-30 10:41:41 +02:00
parent 976606d031
commit 45c3c71513
4 changed files with 10 additions and 5 deletions

View file

@ -31,6 +31,6 @@ a
1
2
3
InnoDB: Last MySQL binlog file position 0 922, file name ./master-bin.000001
InnoDB: Last MySQL binlog file position 0 926, file name ./master-bin.000001
SET DEBUG_SYNC= 'RESET';
DROP TABLE t1;

View file

@ -32,6 +32,6 @@ a
1
2
3
InnoDB: Last MySQL binlog file position 0 922, file name ./master-bin.000001
InnoDB: Last MySQL binlog file position 0 926, file name ./master-bin.000001
SET DEBUG_SYNC= 'RESET';
DROP TABLE t1;

View file

@ -647,11 +647,12 @@ rpl_parallel::do_event(rpl_group_info *serial_rgi, Log_event *ev)
still executing the first ones, to be able to start executing a large
event group without having to wait for the end to be fetched from the
master. And we continue to queue up more events after the first group,
avoiding the overhead of worker threads constantly entering and
leaving the worker thread free list.
so that we can continue to process subsequent parts of the relay log in
parallel without having to wait for previous long-running events to
complete.
But if the worker thread is idle at any point, it may return to the
idle list or be servicing a different request. So check this, and
idle list or start servicing a different request. So check this, and
allocate a new thread if the old one is no longer processing for us.
*/
cur_thread= e->rpl_thread;

View file

@ -57,6 +57,10 @@ struct rpl_parallel_entry {
uint64 last_committed_sub_id;
mysql_mutex_t LOCK_parallel_entry;
mysql_cond_t COND_parallel_entry;
/*
The sub_id of the last event group in this replication domain that was
queued for execution by a worker thread.
*/
uint64 current_sub_id;
rpl_group_info *current_group_info;
/*