Alex, agree to the proposal.
On Thu, Nov 9, 2023 at 5:31 PM Alex Plehanov
wrote:
> Anton,
>
> Async physical logging is a target and most promising solution.
>
> In this scenario:
> 1. Implement logical and physical records split.
> 2. Implement async physical logging (actually, already implemen
Anton,
Async physical logging is a target and most promising solution.
In this scenario:
1. Implement logical and physical records split.
2. Implement async physical logging (actually, already implemented as PoC).
3. Drop solution, implemented in (1) after some time, if solution,
implemented in (
Hi team,
I think there are two solutions to this issue:
1. Removing the "experimental" status of this feature;
2. In the help of control scripts, increase the output of experimental
features.
Which is better?
在 2023/5/17 19:50, 18624049226 写道:
Hi team,
It is understood that the Control Scr
TC bot settings have been modified.
https://tcbot2.sbt-ignite-dev.ru/guard.html
Sincerely,
Vitaliy Osipov
osipov.wita...@gmail.com
ср, 8 нояб. 2023 г. в 10:52, Dmitriy Pavlov :
> Hi Zhenya,
>
> Thank you for noticing.
>
> These builds are being triggered from the TC bot. I've asked Vitaly
In this case, we can split logs to logical and physical at the initial fix.
This should not cause any negative side effects.
And, then implement an async physical logging as an alternative solution?
On Thu, Nov 9, 2023 at 12:52 PM Alex Plehanov
wrote:
> Anton,
>
> My concern is not only about co
Anton,
My concern is not only about compatibility. The new recovery data
storing approach is not a silver bullet, it has drawbacks as well.
Also, we can't be sure that the new approach is applicable for all
environments: increased checkpoint time can lead to throttling or even
OOM in some cases. S
