andrei.el...@pp.inet.fi writes:
> The 10.1 patch is good.
Thanks!
> > Maybe moving deletions from record_gtid() into the background thread is too
> > big a change for 10.1/10.2 ? But we could use the current patch for 10.1,
> > and do the more complicated patch only in 10.3 (or 10.4?).
> >
> > What do you think?
>
> Let's stick your plan.
Ok, great. I'll push this patch (if you have no further questions/comments),
and work on a new patch for 10.3 which moves the delete logic into the
replication background thread.
> But one question,
>>> @@ -662,8 +674,7 @@ rpl_slave_state::record_gtid(THD *thd, const rpl_gtid
>>> *gtid, uint64 sub_id,
>>> + if (rgi)
>>> + {
>>> thd->mdl_context.release_statement_locks();
>>> + /*
>>> + Save the list of old gtid entries we deleted. If this transaction
>>> + fails later for some reason and is rolled back, the deletion of
>>> those
>>> + entries will be rolled back as well, and we will need to put them
>>> back
>>> + on the to-be-deleted list so we can re-do the deletion. Otherwise
>>> + redundant rows in mysql.gtid_slave_pos may accumulate if
>>> transactions
>>> + are rolled back and retried after record_gtid().
>>> + */
>>> + rgi->pending_gtid_deletes_save(gtid->domain_id, elist);
>>> + }
>>> else
>>> + {
>>> thd->mdl_context.release_transactional_locks();
>
>>> + rpl_group_info::pending_gtid_deletes_free(elist);
>>> + }
>
> Why it's not
> rpl_group_info::pending_gtid_deletes_clear()
> called?
Just because in the else-branch we did not run pending_gtid_deletes_save().
pending_gtid_deletes_clear() frees the list previously stored in rgi by
pending_gtid_deletes_save(), while pending_gtid_deletes_free() just frees an
explicitly given list.
Thanks,
- Kristian.
_______________________________________________
Mailing list: https://launchpad.net/~maria-developers
Post to : maria-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~maria-developers
More help : https://help.launchpad.net/ListHelp
