maria-developers team mailing list archive

[Kristian Nielsen <knielsen@xxxxxxxxxxxxxxx>]

"nanyi607rao" <nanyi607rao@xxxxxxxxx> writes:

> Maybe you have encountered this problem and fixed it, that is a DDL
> statement Query event has a Gtid event ahead, but has no end_event (like
> xid_event, commit or rollback) behind. so in the latest codes of parallel
> replication, count_queued_event_groups will increase but
> count_committing_event_groups will not for DDL. it would lead next
> event_group wait forever I guess.

Hm, the way it is supposed to work is this:

A DDL like CREATE TABLE is logged as two events:

1. A GTID_EVENT with the FL_STANDALONE flag set
2. A QUERY_EVENT with the CREATE TABLE statement

(no end event, as you wrote. The FL_STANDALONE flag in the GTID_EVENT is used
to handle the case where there is a GTID event but no end event).

In handle_rpl_parallel_thread(), group_standalone will be true because the
FL_STANDALONE flag is set. Then end_of_group will also be true, because of
this condition:

    (group_standalone && !Log_event::is_part_of_group(event_type))

(is_part_of_group() is false for a QUERY_EVENT).

Then the code will call into finish_event_group() which calls
rgi->mark_start_commit_no_lock(), which does
++e->count_committing_event_groups.

So as far as I can see, things should work correctly also for DDL. Does this
make things clearer for you? Or is there some problem with the code that I
missed in the above explanation?

Thanks,

 - Kristian.