Zardosht Kasheff writes:
> to implement commit_ordered, I would like to. I think what you are
> stating is that if the handlerton does some bookkeeping of
> transactions that have been prepared, then when
> commit_checkpoint_request is called, we can use this bookkeeping to
> properly call commit
Hello Kristian,
Thanks for the replies to both emails. I think at this point my
biggest interest is learning how to ensure that in Maria 10.0, we can
choose to not fsync our log on commit. If I can do this without having
to implement commit_ordered, I would like to. I think what you are
stating is
Zardosht Kasheff writes:
> Reading the email, I think this is what is happening. You depend on
> commit_ordered to order the transactions in the engine, and when the
> binary log is going to rotate, you call commit_checkpoint_request on
> the last transaction in that order. When that returns, we
Zardosht Kasheff writes:
> Here is a very high level overview.
Thanks for the detailed explanation!
I think an easy way to implement commit_ordered() is that all you do is
increment a counter and assign it to the transaction. Then in commit(), each
transaction waits for the previous commit to w
In this email, I will continue discussion on 10.0, as I think my
questions for 5.5 have been resolved.
Reading the email, I think this is what is happening. You depend on
commit_ordered to order the transactions in the engine, and when the
binary log is going to rotate, you call commit_checkpoint_
Kristian, thank you for the detailed reply. My MariaDB 5.5 questions
have been answered. So in this email, I will move on and explain a bit
what commit does in TokuDB during commit. In another email, I will
continue discussion on 10.0.
Here is a very high level overview.
In TokuDB, all work to mo
Kazuhiko Shiozaki writes:
> I tried setting SERIALIZABLE isolation globally and confirmed that
> (much) more deadlocks happened. But unfortunately "Duplicate entry"
> error still happens.
>
>@@GLOBAL.tx_isolation: SERIALIZABLE
> @@tx_isolation: SERIALIZABLE
> @@innod
Zardosht Kasheff writes:
> I am investigating what our storage engine, TokuDB, needs to do to
> achieve its best performance in MariaDB 5.5 with respect to preparing
> and committing transactions, and with respect to binary logging.
Great!
> - In MariaDB 5.5, we must fsync our recovery log on
8 matches
Mail list logo
