Tungsten consistency checking technology works very well, and there
is no need to "fix it" in any way. However, this method is not directly
usable for multi master replication, because the target node(s) may
have committed some transactions not yet seen in the originating
master node, and these new transactions can interfere with the
consistency check query.
I'm sure I should really know this already, but does your statement amount
to saying the consistency check needs to execute in total order with other
change sets? Or are there other data visibility issues along the lines of
non-repeatable reads that would cause you to get different answers on
different servers?