stacks-inspect
: add index-range
option to replay-blocks
#4885
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
This adds the
index-range
option toreplay-blocks
. This is useful for selecting a uniformly random slice of blocks for replay (because ordering by index block hash is indistinguishable from a pseudorandom function).Note: As part of this PR, I also considered making the
replay-blocks
command alter the SQLite transaction behavior from IMMEDIATE to DEFERRED. The goal was to allow multiple processes to share a chainstate directory during replay-blocks. Unfortunately, this didn't really help, becausereplay-blocks
does perform writes in its transactions: it just rolls back those transactions. This means that SQLite will try to obtain a write lock even in DEFERRED operation.However, one workable strategy for avoiding storage overhead when trying to run multiple process with
replay-blocks
is to copy the whole chainstate directory except forchainstate/vm/clarity/marf.sqlite.blobs
, and then simply symlink that file for each instance of the replay-blocks processes. That file isn't a database, so it doesn't lock on transactions (and this is safe because none of the replay-blocks processes actually write to that file). This file is also ~75% of the chainstate's disk size.