maria-developers team mailing list archive

[Kristian Nielsen <knielsen@xxxxxxxxxxxxxxx>]

Kristian Nielsen <knielsen@xxxxxxxxxxxxxxx> writes:

> The patch makes later transactions wait for earlier transactions to commit
> before committing themselves.

Hm, I now realise a problem with this approach :-/

The problem is with MyISAM tables, or other tables that use table-level
locking instead of row-level locking.

If transactions T1 and T2 both update the same table mytable, then it can
happen that T2 runs first and gets a table lock on table mytable. T1 then has
to wait for T2 to commit, after which the table lock is released. But T2 will
never commit, it will wait for T1 to commit first with my patch. Thus we have
a deadlock.

One way to fix this could be to extend your algorithm for detecting conflicts
between different transactions. If some table T uses table-level locking, then
put into the hash just the table name, without any primary key values. Then
any two such transactions will be considered conflicting, and we avoid the
deadlock. No loss of parallelism should occur, as two updates to the same
MyISAM table can anyway not run in parallel.

So there seems to be a solution, but it is somewhat more complex that I had
hoped. I will ask Monty to help if/how the code can know in general that a
table uses table-level locking. I also worry that there can be other problems
that can cause such a deadlock. This would be bad, as it would require the
user/DBA to discover this and manually kill the stuck thread.

On the other hand, it would be really nice to get in-order commit, this will
make it much easier to integrate the parallel replication into MariaDB. For
example, I do not know how to get this parallel replication working properly
with global transaction ID without in-order commit.

 - Kristian.