maria-developers team mailing list archive

[Kristian Nielsen <knielsen@xxxxxxxxxxxxxxx>]

Paul McCullagh <paul.mccullagh@xxxxxxxxxxxxx> writes:

> Hi Kristian,

Hi Paul, thanks for your detailed answer!

> I was a bit difficult to explain, so please ask if anything is not
> clear.

It seems pretty clear from your explanation. I will take a look into the
sources, and will let you know if I have any questions.

> Without write or flush, this is a very fast operation. But the
> transaction is still committed and ordered, it is just not durable.

Cool. Note that when using 2-phase commit (which happens if the binlog is
enabled or if multiple engines participate in the transaction), the
transaction is effectively durable at the server level (TC will recover it in
case of crash), though at the engine level it is not. And in fact the
transaction is already potentially visible to slaves.

[This got me thinking about the case where there is no 2-phase commit (no
binlog, and no other participating engines). In this case the transaction is
_not_ durable at the server level until after commit in the engine. So I do
not like enforcing visibility in commit_ordered() in this case.

But when there is no 2-phase commit, there is no benefit in commit_ordered()
anyway. So I think I will have the server only use commit_ordered() for
2-phase commit, similar as to prepare(). Slightly more book-keeping for the
engines, but saner sematics in the end.

Anyway, this is not really PBXT specific, but your mail inspired me to think
about it, so thanks!]

 - Kristian.