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.