aboutsummaryrefslogtreecommitdiff
path: root/test
diff options
context:
space:
mode:
authorTheCharlatan <seb.kung@gmail.com>2024-05-17 12:48:09 +0200
committerTheCharlatan <seb.kung@gmail.com>2024-06-07 19:17:19 +0200
commit201c1a92824c71ae646d5bba9963871b1d704cc1 (patch)
treed01381e62f861e3f2d7fc3e7992c3ea97f590e06 /test
parent804f09dfa116300914e2aeef05ed9710dd504e8c (diff)
downloadbitcoin-201c1a92824c71ae646d5bba9963871b1d704cc1.tar.xz
indexes: Don't wipe indexes again when already reindexing
Before this change continuing a reindex without the -reindex flag set would leave the block and coins db intact, but discard the data of the optional indexes. While not a bug per se, wiping the data again is wasteful, both in terms of having to write it again, and potentially leading to longer startup times. When initially running a reindex, both the block index and any further activated indexes are wiped. On an index's Init(), both the best block stored by the index and the chain's tip are null. An index's m_synced member is therefore true. This means that it will process blocks through validation events while the reindex is running. Currently, if the reindex is continued without the user re-specifying the reindex flag, the block index is preserved but further index data is wiped. This leads to the stored best block being null, but the chain tip existing. The m_synced member will be set to false. The index will not process blocks through the validation interface, but instead use the background sync once the reindex is completed. If the index is preserved (this change) after a restart its best block may potentially match the chain tip. The m_synced member will be set to true and the index can process validation events during the rest of the reindex.
Diffstat (limited to 'test')
0 files changed, 0 insertions, 0 deletions