Binbin

Currently the time is, a successful fork, when it start, is recorded. We can also record the last failed fork time if needed.

> Were these config files and text file committed by accident? yes.. sorry for that, i did not check after push

> I suppose the counter question I have is what is the specific use case here when we have the logs for when it actually started? We shouldn't recommend relying...

> My concern was that if someone was concerned about a latency event that was 5 minutes ago, and there was a last fork time that was 180 seconds ago,...

I may have missed something or misjudged something. It is really difficult to define whether some commands are FAST or SLOW. Push the current commit first (i am a bit...

> Would it be more economical to flag the SLOW commands and have everything else be FAST by default? yes, i think that will be. In other words, i'm also...

> Maybe we should have FAST for the commands that are always fast and SLOW for commands that are always slow. For other commads we don't need any of these...

Here is the logs: The old primary: ``` # The old primary, restarting 2024-08-30T05:51:13.1503179Z ### Starting test Restarting the previously killed master nodes in tests/unit/cluster/manual-takeover.tcl # Get configEpoch collision with...

> The PR description can be updated to explain the solution. Now it is just copy-pasted from the issue. :) The issue desc is good and very detailed so i...

Sorry for the late reply, i somehow missed this thread. > I didn't think about this. The replica can't do psync to the new primary after failover? If it can't,...