Right now the log is only GC'd during commits when the global_min_accept and commit_num align. The other opportunity to do this is when global_min_accept is incremented to reach thecommit_num. This occurs when a node has been down and then recovers. If operations were committed while this node was down they won't be garbage collected because they don't exist on all nodes. When the down node recovers those commits will be reflected before the primary receives the prepareOk messages and sends the updated global_min_accept. It is now possible to garbage collect, although garbage collection doesn't happen until the next commit. We can optimize this to free memory earlier by doing the garbage collection when the global_min_accept count changes also.
This isn't crucial right now since reads and writes are in the log and commits are frequent. However if writes are few and far between and reads don't cause commits (as is planned) then this will become a necessary optimization.
Right now the log is only GC'd during commits when the
global_min_acceptandcommit_numalign. The other opportunity to do this is whenglobal_min_acceptis incremented to reach thecommit_num. This occurs when a node has been down and then recovers. If operations were committed while this node was down they won't be garbage collected because they don't exist on all nodes. When the down node recovers those commits will be reflected before the primary receives theprepareOkmessages and sends the updatedglobal_min_accept. It is now possible to garbage collect, although garbage collection doesn't happen until the next commit. We can optimize this to free memory earlier by doing the garbage collection when theglobal_min_acceptcount changes also.This isn't crucial right now since reads and writes are in the log and commits are frequent. However if writes are few and far between and reads don't cause commits (as is planned) then this will become a necessary optimization.