Skip to content

Prevent pruning objects other transactions depend on

Sami Hiltunen requested to merge smh-tx-mgr-out-of-order-close into master

TransactionManager has an issue with pruning operations currently which may lead to corrupting repositories. While the pruning runs, other transactions perform writes that rely on unreachable objects that the pruning run would remove. This may happen if they write objects into the repository that depend on said unreachable objects or by pointing a reference to an unreachable object.

Currently the pruning conflict checks are only accounting for references being pointed to the unreachable objects. It doesn't consider new unreferenced objects written into the repository. This may lead to corruption if we prune objects that are made reachable in later transactions.

Fix the issue by aborting the pruning transaction if it attempts to prune any object that another concurrently committed transaction depends upon. To do so, we store the object dependencies in the committedEntries and check that all of the dependencies still exist after the pruning would be applied.

The object dependencies are currently kept in-memory. We don't write them out to the WAL entry on the disk as they are only needed for synchronization for the verification process. Conflict checking related state doesn't need to be persisted not replicated.

Closes #6083 (closed)
Closes #6080 (closed)

Edited by Sami Hiltunen

Merge request reports