Hm, that assert is wrong:

const rpl_gtid *gtid= state->find(glev->list[i].domain_id);
if (!gtid)

It is correct in the first iteration of the loop, but as we delete from the
`state' hash in the loop, the condition may no longer hold in subsequent
iterations of the loop. So the assert should just be removed.

I will check that everything else is ok with the supplied test case (thanks
for supplying that, made it very easy to reproduce the problem).

Note though contains_all_slave_gtid() returns true for slave_log.00003 when server 3 tries to connect to server 2 which is wrong because some events become skipped in slave_log.00002.

Yes, I've noticed, thanks.

I'll fix.

BTW, I noticed that your test has --sync_with_master in server_3, but not server_2 (for the initial events on server 1). I assume this is just an oversight, because without it the test becomes non-deterministic (it will fail if server 2 slave threads happen to stop before they replicated everything from server 1)

Ok, so there was a deeper issue here.

Suppose binlog file X has in its Gtid_list_event: 0-1-3,0-2-5, and suppose the
slave requests to start replicating after 0-1-3.

In this case the bug was that master would start sending events from the start
of X. This is wrong, because 0-2-4 and 0-2-5 are contained in X-1, and are
needed by the slave. So these events were lost.

On the other hand, if the slave requested 0-2-5, then it is correct to start
sending from the beginning of binlog file X, because 0-2-5 is the last GTID
logged in earlier binlogs. The difference is that 0-2-5 is the last of the
GTIDs in the Gtid_list_event. The problem was that the code did not check that
the matched GTID was the last one in the list.

Fixed by checking if the gtid requested by slave that matches a gtid in the
Gtid_list_event is the last event for that domain in the list. If not, go back
to a prior binlog to ensure all needed events are sent to slave.

I pushed the fix to 10.0-base.
Patch: revid:knielsen@knielsen-hq.org-20130503092729-gedp152b19k5wdnj

Kristian,
So why do you think it's necessary to store gtid for each server_id in gtid_list? Why not store one gtid per domain?

And am I right that if some server was master, then failed over to another master and then ceased to exist altogether gtid with its server_id will exist indefinitely in the gtid_list in the binlogs of every server? Don't you think it's a problem and a way to accumulate a lot of unnecessary garbage? How will everything behave if gtid_list contains 1000 or 10,000 different gtid records?

OK, I see your response on maria-developers list. I'll move the discussions there.