maria-developers team mailing list archive

[andrei.elkin@xxxxxxxxxx]

Sujatha, howdy.

Thank you for spelling it out for me!

> Hello Andrei,
...
>>>
>>> Analysis:
>>> =========
>>> Enabling "replicate_annotate_row_events" on slave, Tells the slave to write
>>> annotate rows events received from the master to its own binary log. The
>>> received annotate events are applied after the Gtid event as shown below.
>>> thd->query() will be set to the actual query received from the master, through
>>> annotate event. Annotate_rows event should not be deleted after the event is
>>> applied as the thd->query will be used to generate new Annotate_rows event
>>> during applying the subsequent Rows events.
>> [ here ]
>>    The Table_map and Rows_log_event that follow do not touch thd->query().
>
> The Table_map and Rows_log_event that follow "Annotate_rows" event do
> make use of "thd->query()".

Frankly I did not expect that. Perhaps it would have not been a bad idea
to make Annotate_rows_log_event::do_apply_event() logging of
itself, which still makes sense even if the slave applier will filter
out its group's Rows_log_event:s so in this case the slave side event group
would consists of mere Annotate.

The above is a mere remark though, I have to accept what we have.

>>
>> I also suggest to check out mysqlbinlog run. There seems to be no test
>> for that though, so one needs to be written. The goal would be to prove
>> a created binlog output is as expected (e.g to include Annotate).
>
>
> Sure, I will add a test case.

Super! The patch is approved then.

Cheers,

Andrei