Patch for review: http://lists.askmonty.org/pipermail/commits/2014-July/006275.html

Hm, I think that patch is not enough.

We also need to handle the case where the master crashes after writing only part of a transaction into the binlog. In this case, the following format description event is used to notify of the partial event group that must be rolled back.

So I think when the FD event is encountered, we need to queue some marker event that tells the worker thread with the partial event group to roll back, otherwise we will deadlock with FD event waiting for group to complete and group waiting for FD event to know it must roll back...

Patches for review:

http://lists.askmonty.org/pipermail/commits/2014-August/006421.html

http://lists.askmonty.org/pipermail/commits/2014-August/006423.html

Assigning to Monty for review, as agreed on the IRC

Review for patch 1

void
+rpl_parallel::wait_for_workers_idle(THD *thd)
+{
+ uint32 i, max_i;
+

Add a comment why we don't need a mutex while we loop over
domain_hash. (I noticed we do this a lot in the code already, but
didn't find any comment why this is safe).

I assume this is because this is called by the driver thread and it's
only the driver thread that can cause things to be inserted into
domain_hash?

+ max_i= domain_hash.records;
+ for (i= 0; i < max_i; ++i)
+ {
+ bool active;
+ wait_for_commit my_orderer;
+ struct rpl_parallel_entry *e;
+
+ e= (struct rpl_parallel_entry *)my_hash_element(&domain_hash, i);
+ mysql_mutex_lock(&e->LOCK_parallel_entry);
+ if ((active= (e->current_sub_id > e->last_committed_sub_id)))
+

+ mysql_mutex_unlock(&e->LOCK_parallel_entry);
+ if (active)
+

+ }
+}

<cut>

+ if (typ == FORMAT_DESCRIPTION_EVENT)
+ {
+ Format_description_log_event *fdev=
+ static_cast<Format_description_log_event *>(ev);
+ if (fdev->created)
+

+ }

What happens if one of the thread we are waiting for fails and has to
rollback or if wait_for_workers_idle() is interupted by a kill while we are
in wait_for_prior_commit() ?

Will rli->abort_slave or sql_thread_stopping be set in this case so
that we don't drop the temporary tables while the other thread is
retrying the statement ?

Appart for the above questions, I don't have any other comments.

Regards,
Monty

Done. See comments

> What happens if one of the thread we are waiting for fails and has to
> rollback or if wait_for_workers_idle() is interupted by a kill while we are
> in wait_for_prior_commit() ?

Good catch, if the SQL driver thread gets killed while in this wait, the code
would drop temporary tables without completing the wait. I've fixed it to
catch the kill and return an error in this case (normally the SQL driver
thread should not be killed, but better to handle this correctly in any case).

If one of the threads we are waiting for returns failure from
wait_for_prior_commit(), then it means that this thread has received a fatal
error and will no longer execute any events, so that's fine.

(If a thread gets a temporary error and needs to retry a transaction, it will
not wake up any wait_for_prior_commit() until the retry succeeded or a fatal
error occured).

Thanks for review!

Pushed to 10.0