Andrei via developers <developers@lists.mariadb.org> writes:
Let me admit, in the external loop description
>> It is better to do as in the original patch, and treat commit-by-rotate like
>> a normal binlog rotate, not try to participate that transaction in binlog
>> group commit. We cannot share the fsync anyway, as the files are different.
>> And it introduces a lot of complexities to suddenly have binlog rotations in
>> the middle of group commit - what about the complex accounting around
>> xid_count and binlog checkpoints? There will be a lot of corner cases eg. if
>> _two_ commit-by-rotate happens in the same group commit, with lots of
>> potential for subtle bugs that will occur only very rarely in production and
>> be almost impossible to track down.
>
> I gave some thought to these use cases and was confident they would be
> covered.
> To that matter, the interspersed with rotate group write of `287511a7...`
> commit
> can be arranged as an external loop
>
> + for (current= queue; current != NULL; current= current->next)
> + {
> if (likely(is_open())) // Should always be true
> {
> ...
> for (; /* current fits to the active log */; current= current->next)
> { ... /* flush */ ...}
> flush_and_sync();
> ...
> +/- rotate(false, &check_purge);
> }
> ...
> trx_group_commit_with_engines();
> + }
the flush and commit phases are to run according to a special mutex lock
protocol. The external loop if taken literarly can't of course do that
e.g for a reason of concurrent leaders should be held off.
_______________________________________________
developers mailing list -- developers@lists.mariadb.org
To unsubscribe send an email to developers-le...@lists.mariadb.org
