Hi, Kristian! On Jul 03, Kristian Nielsen wrote: > Sergei Golubchik <s...@mariadb.org> writes: > > > I'm kind of lost here. I really don't like requiring engines to do more > > obligatory things, but I don't see a good way around it either. > > Agree, that's how I felt while trying to think of _any_ way to solve these > problems. I ended up with current solution, but not entirely happy about it. > > At least, we have some more ideas now to improve things. > > What should be the next step?
As you suggested on irc, it would make sense to make a smaller innodb/xtradb only fix in 10.0 and a more engine-friendly, with the new api, in 10.1 > > I thought that if a transaction is rolled back, you can, technically > > force *all* later transactions to roll back too and redo them all. > > But that'd be kind of expensive. > > It's not the expensive that worries me. The problem is that some of > the following transactions may not be possible to roll back. Ah, yes, indeed. We could still 1. rollback regardless and possibly break replication in this case. saying that a transactional engine will work without modifications in most cases, but not when it's mixed with non-trans updates 2. as discussed, have a flag to mark non-trans-updates transactions and don't run them in parallel at all. then a transactional engine will work without modifications. but that's for 10.1, if we do innodb-only fix in 10.0, it means we aren't concerned with other engines there. > But in some cases the deadlock, kill, and retry is unnecessary. This is about > the issue in MDEV-5914, for example: > > T1: UPDATE t1 SET secondary=NULL WHERE primary=1 > T2: DELETE t1 WHERE secondary <= 3 > > If T1 and T2 were group-committed together on the master, we know that it is > safe to run them in parallel, so we can relax the gap lock taken by T2 that > can block T1. Then we avoid having to rollback and retry T2. > > But if T2 committed in a different group commit on the master, we do not know > that this relaxing of gap locks is safe. Because T2 may still run in parallel > with the COMMIT of T1, we need to keep the gap locks, so that T2 will wait if > it needs to access any row modified by T1. How can T2 run in parallel with T1 if they're from different groups? > The reason I think my original API is simpler is that there is just > one very simple thing that the engine must do: call > thd_report_wait_for(T1,T2) whenever T1 is about to wait until T2 > commits. Everything else is optional optimisations that can be safely > ignored. It seems that any conceivable engine must already have easy > access to knowledge about one transaction needing to wait for another. > And indeed, in InnoDB only a couple of lines need to be added to > handle this. So it is very simple to use. > With your suggestion, however, things are more complex for the engine. > It needs to implement additional deadlock detection, based on some > enforced commit order. The very concept of "enforced commit order" is > probably something new. And it needs to implement some way to resolve > deadlocks with another transaction T2 that may or may not be running > inside the engine. So again, a new concept is introduced, "Is > transaction T running inside this engine"? Hmm, okay... When you put it this way, it does sound simpler. Allright, let's keep thd_report_wait_for() :) Regards, Sergei _______________________________________________ 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
