Hi, Kristian! On Jan 11, Kristian Nielsen wrote:
Sergei Golubchik <serg@mariadb.org> writes:
To the question of the usage of trX cache by non-trX let me answer broadly to mention @@binlog_direct_non_transactional_update = false leads to aggregation of mixed, say innodb + myisam, events in trx cache.
That's different. The bug summary is "GTID event falsely marked transactional", meaning, the group of events is not transactional and it's falsely marked as transactional. If you have an innodb/myisam mix, it is correctly marked transactional.
Jumping into a disucssion here, so apologies if I misunderstood, but...
In a way :) It doesn't answer any of my questions, but it's an important insight - I didn't know that and how I have even more questions. Thanks for this clarification, it was very helpful!
The point of the "transactional" mark in GTID is to inform parallel replication that the entire event group is safe for optimistic parallel replication - basically that it can be rolled back.
So if a event group contains innodb/myisam mix, and is marked as "transactional", that is not correct. This would allow parallel replication to speculatively execute and roll back the mix, and the myisam changes would remain and cause replication to break.
Andrei, so now I have not one but two use cases: 1. InnoDB and FederatedX (or any other transactional but not XA-capable engine) in one transaction - this transaction can be speculatively executed and rolled back if needed. But it doesn't end with Xid_log_event, and after your patch it won't have the trans flag. 2. InnoDB and MyISAM. This "transaction" cannot be rolled back, so must not be executed speculatively. But it does end with a Xid_log_event, so it seems that you'll put a trans flag on it. The first case is a performance issue, but not a problem of correctness. Some some transactions might not be executed speculatively, but everything will still work. The second case can break replication when a speculatively executed InnoDB+MyISAM "transaction" will fail to roll back. Regards, Sergei VP of MariaDB Server Engineering and security@mariadb.org