maria-developers team mailing list archive

[Sergei Golubchik <serg@xxxxxxxxxxx>]

Hi, Kristian!

On Jan 11, Kristian Nielsen wrote:
> Sergei Golubchik <serg@xxxxxxxxxxx> 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@xxxxxxxxxxx