Andrei Elkin <andrei.el...@mariadb.com> writes:
>> 1. I have not so far been able to reproduce the failure, so this patch is
>> assumed to fix the sporadic failure, but I have not been able to verify that
>> it does.
>
> I verified your analysis to confirm.
Thanks for checking!
>> But on the other hand this will not solve the fundamental issue, that until
>> the
>> GTID mode connect is completed, we will in the general case not have a valid
>> corresponding old-style position. So maybe the current behaviour is
>> ok?
> Sure but it looks fixes are not overly difficult.
>
> As it's Gtid_list_log_event::log_pos that makes the file:pos (old-style
> coordinates)
> state be valid why won't be keep the coordinates intact until the event
> has been arrived/processed? Say that situation is remembered in
> `RLI::seen_gtid_log_list_event`.
> Then for instance in the serial case the fixes would look like
>
> --- a/sql/rpl_rli.cc
> +++ b/sql/rpl_rli.cc
> @@ -1030,7 +1030,7 @@ void Relay_log_info::inc_group_relay_log_pos(ulonglong
> log_pos,
> rgi->last_master_timestamp > last_master_timestamp)
> last_master_timestamp= rgi->last_master_timestamp;
> }
> - else
> + else if (!mi->using_gtid || seen_gtid_log_list_event)
> {
> /* Non-parallel case. */
> group_relay_log_pos= event_relay_log_pos;
Agree, this looks fine.
The dump thread should always be sending the gtid_list event. And yes, the
log_pos of the events received until then are not useful to set for the
slave.
Right, so this seems a good approach for a fix.
Maybe I should push the workaround to 10.5 to help the effort to remove
sporadic failures, and then file a separate bug about the underlying problem
and your proposed solution?
Thanks,
- Kristian.
_______________________________________________
developers mailing list -- developers@lists.mariadb.org
To unsubscribe send an email to developers-le...@lists.mariadb.org
