New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Optimize reindex #7917

Merged
merged 5 commits into from May 18, 2016

Conversation

Projects
None yet
6 participants
@sipa
Member

sipa commented Apr 20, 2016

Several changes:

  • Make reindex/import use AcceptBlock rather than ProcessNewBlock, so activation of the resulting best chain is delayed.
  • That delayed activation is handled by the existing "Activating best chain" step in the startup process, which is moved to ThreadImport.
  • Optimize ActivateBestChain to not walk the entire chain to find the most work chain to connect for each block (O(n^2) -> O(n)).

This has several advantages:

  • As the actual activation is done after all blocks have been added back to the index, it gets to use the checkpoints information (better progress indicator, skipping of signature checks, ...).
  • Having a block index with many unactivated blocks (for example, after deleting the chainstate directory) becomes much faster
  • That case also runs in the background now (as it's simply treated as part of the importing process).

Downsides:

  • All blocks are read twice from disk during reindex (once to rebuild the index, once to activate).

Todo:

  • Better progress indicator during the index rebuild phase.
@laanwj

This comment has been minimized.

Show comment
Hide comment
@laanwj

laanwj Apr 20, 2016

Member

Good to see this!

All blocks are read twice from disk during reindex (once to rebuild the index, once to activate)

Could this (theoretically) be avoided by just reading the header during the initial scan? after all, the extra header that we tack on includes the size of the block, so we could skip the rest the first time.

Member

laanwj commented Apr 20, 2016

Good to see this!

All blocks are read twice from disk during reindex (once to rebuild the index, once to activate)

Could this (theoretically) be avoided by just reading the header during the initial scan? after all, the extra header that we tack on includes the size of the block, so we could skip the rest the first time.

@sipa

This comment has been minimized.

Show comment
Hide comment
@sipa

sipa Apr 20, 2016

Member

@laanwj Yes, I've considered that. That could lead to an inconsistent block index though (as in: I'm not sure whether there are any internal assumptions that all entries in the block index are valid).

Member

sipa commented Apr 20, 2016

@laanwj Yes, I've considered that. That could lead to an inconsistent block index though (as in: I'm not sure whether there are any internal assumptions that all entries in the block index are valid).

@jonasschnelli

This comment has been minimized.

Show comment
Hide comment
@jonasschnelli

jonasschnelli Apr 20, 2016

Member

Nice. Concept ACK.
Testing this now on a mainnet node -reindex.

Member

jonasschnelli commented Apr 20, 2016

Nice. Concept ACK.
Testing this now on a mainnet node -reindex.

@sipa

This comment has been minimized.

Show comment
Hide comment
@sipa

sipa Apr 20, 2016

Member

@laanwj Another problem with that approach: say you get a block corrupted near the chain tip on disk, you find it and do a reindex. You expect it to reindex up to that corrupted block and then start back from network. Instead, if you don't do transaction validation during the rebuild loop, it may happily add the block to the index, and have activation fail (making it mark the chain as invalid).

Member

sipa commented Apr 20, 2016

@laanwj Another problem with that approach: say you get a block corrupted near the chain tip on disk, you find it and do a reindex. You expect it to reindex up to that corrupted block and then start back from network. Instead, if you don't do transaction validation during the rebuild loop, it may happily add the block to the index, and have activation fail (making it mark the chain as invalid).

@laanwj

This comment has been minimized.

Show comment
Hide comment
@laanwj

laanwj Apr 20, 2016

Member

Yes, it would be quite more complex to handle those issues well.
In any case if the speed-up is more than the extra disk i/o that this generates takes, it doesn't matter, no need to worry about it in this pull.

Member

laanwj commented Apr 20, 2016

Yes, it would be quite more complex to handle those issues well.
In any case if the speed-up is more than the extra disk i/o that this generates takes, it doesn't matter, no need to worry about it in this pull.

@sipa

This comment has been minimized.

Show comment
Hide comment
@sipa

sipa Apr 20, 2016

Member

@jonasschnelli If you feel like benchmarking, an interesting thing to test is (reindex on master) vs (deleting chainstate on this PR), both with signature checks hackishly disabled. Deleting of chainstate caused a very slow, foreground, and (before #7821) uninterruptible process earlier. With this PR is should be (nearly) the same speed as an old reindex.

Member

sipa commented Apr 20, 2016

@jonasschnelli If you feel like benchmarking, an interesting thing to test is (reindex on master) vs (deleting chainstate on this PR), both with signature checks hackishly disabled. Deleting of chainstate caused a very slow, foreground, and (before #7821) uninterruptible process earlier. With this PR is should be (nearly) the same speed as an old reindex.

@sipa

This comment has been minimized.

Show comment
Hide comment
@sipa

sipa Apr 20, 2016

Member

Would it be useful to have a -weakreindex or -rebuild now, which does not throw out the block index, and only the chainstate? That would be faster, as it wouldn't need the rebuild phase.

Member

sipa commented Apr 20, 2016

Would it be useful to have a -weakreindex or -rebuild now, which does not throw out the block index, and only the chainstate? That would be faster, as it wouldn't need the rebuild phase.

@laanwj

This comment has been minimized.

Show comment
Hide comment
@laanwj

laanwj Apr 20, 2016

Member

Would it be useful to have a -weakreindex or -rebuild now, which does not throw out the block index, and only the chainstate? That would be faster, as it wouldn't need the rebuild phase.

Would need better reporting about what database is corrupted for that to be useful to end-users. But even without that I can see that being very useful for benchmarking the UTXO database.

I like the idea of being able to rebuild databases separately. What about the other way around? If you have a UTXO set, but want to reindex the block chain? (e.g. when switching a pruned node to a non-pruned one by copying block data from another node)

If it was up to me I wouldn't use the name 'weakindex' or 'rebuid' (that's another one for the rescan, reindex, re.... category of vaguenes) but call it what it is: -rebuild-blockindex -rebuild-chainstate etc (using the same name as the db directory names).

Member

laanwj commented Apr 20, 2016

Would it be useful to have a -weakreindex or -rebuild now, which does not throw out the block index, and only the chainstate? That would be faster, as it wouldn't need the rebuild phase.

Would need better reporting about what database is corrupted for that to be useful to end-users. But even without that I can see that being very useful for benchmarking the UTXO database.

I like the idea of being able to rebuild databases separately. What about the other way around? If you have a UTXO set, but want to reindex the block chain? (e.g. when switching a pruned node to a non-pruned one by copying block data from another node)

If it was up to me I wouldn't use the name 'weakindex' or 'rebuid' (that's another one for the rescan, reindex, re.... category of vaguenes) but call it what it is: -rebuild-blockindex -rebuild-chainstate etc (using the same name as the db directory names).

@sipa

This comment has been minimized.

Show comment
Hide comment
@sipa

sipa Apr 20, 2016

Member

I like the idea of being able to rebuild databases separately. What about the other way around? If you have a UTXO set, but want to reindex the block chain? (e.g. when switching a pruned node to a non-pruned one by copying block data from another node)

You can just overwrite your blocks/ database with another version (including its index), as long as it has your currently active chain in it.

Member

sipa commented Apr 20, 2016

I like the idea of being able to rebuild databases separately. What about the other way around? If you have a UTXO set, but want to reindex the block chain? (e.g. when switching a pruned node to a non-pruned one by copying block data from another node)

You can just overwrite your blocks/ database with another version (including its index), as long as it has your currently active chain in it.

@sipa

This comment has been minimized.

Show comment
Hide comment
@sipa

sipa Apr 20, 2016

Member

If it was up to me I wouldn't use the name 'weakindex' or 'rebuid' (that's another one for the rescan, reindex, re.... category of vaguenes) but call it what it is: -rebuild-blockindex -rebuild-chainstate etc (using the same name as the db directory names).

-rebuild-chainstate sounds like an excellent idea. I don't know what -rebuild-blockindex would mean though...

Member

sipa commented Apr 20, 2016

If it was up to me I wouldn't use the name 'weakindex' or 'rebuid' (that's another one for the rescan, reindex, re.... category of vaguenes) but call it what it is: -rebuild-blockindex -rebuild-chainstate etc (using the same name as the db directory names).

-rebuild-chainstate sounds like an excellent idea. I don't know what -rebuild-blockindex would mean though...

@sipa

This comment has been minimized.

Show comment
Hide comment
@sipa

sipa Apr 21, 2016

Member

Added a commit to implement -reindex-chainstate.

I guess the semantics for -reindex-blockindex could be:

  • Rebuild the block index without rebuilding the chainstate
  • If afterwards the chainstate's tip is in the resulting block index, mark every block on the best chain as validated and pretend nothing happened
  • If not, wipe the chainstate and rebuild that as well.
Member

sipa commented Apr 21, 2016

Added a commit to implement -reindex-chainstate.

I guess the semantics for -reindex-blockindex could be:

  • Rebuild the block index without rebuilding the chainstate
  • If afterwards the chainstate's tip is in the resulting block index, mark every block on the best chain as validated and pretend nothing happened
  • If not, wipe the chainstate and rebuild that as well.
@laanwj

This comment has been minimized.

Show comment
Hide comment
@laanwj

laanwj Apr 21, 2016

Member

I don't know what -rebuild-blockindex would mean though...

That hypothetical option would rebuild the blockindex database, say after some new-fangled corruption check detects that that database was corrupted.

  • Throw away the block index (so the database in blocks/index)
  • Reindex blocks

But don't touch the chain state in any way, it is assumed to be still good. If the best chain is not included after reindexing the blocks, throw another error that a full reindex -reindex-chainstate is necessary.

I guess the semantics for -reindex-blockindex could be:

Yes, something like that, sounds good to me.

Member

laanwj commented Apr 21, 2016

I don't know what -rebuild-blockindex would mean though...

That hypothetical option would rebuild the blockindex database, say after some new-fangled corruption check detects that that database was corrupted.

  • Throw away the block index (so the database in blocks/index)
  • Reindex blocks

But don't touch the chain state in any way, it is assumed to be still good. If the best chain is not included after reindexing the blocks, throw another error that a full reindex -reindex-chainstate is necessary.

I guess the semantics for -reindex-blockindex could be:

Yes, something like that, sounds good to me.

@dcousens

This comment has been minimized.

Show comment
Hide comment
@dcousens

dcousens Apr 22, 2016

Contributor

concept ACK -(rebuild|reindex)-*

Contributor

dcousens commented Apr 22, 2016

concept ACK -(rebuild|reindex)-*

@sipa

This comment has been minimized.

Show comment
Hide comment
@sipa

sipa Apr 22, 2016

Member

I tried implementing -reindex-blockindex, but it is significantly harder: it would mean first initializing with a dummy chainstate, then reindexing the blockindex while leaving the original chainstate untouched, then stopping the node, loading the real chainstate, marking the blocks along the best chain as valid (or fail if not found anymore), and starting the node again.

Member

sipa commented Apr 22, 2016

I tried implementing -reindex-blockindex, but it is significantly harder: it would mean first initializing with a dummy chainstate, then reindexing the blockindex while leaving the original chainstate untouched, then stopping the node, loading the real chainstate, marking the blocks along the best chain as valid (or fail if not found anymore), and starting the node again.

@laanwj

This comment has been minimized.

Show comment
Hide comment
@laanwj

laanwj Apr 26, 2016

Member

Going to test this

Member

laanwj commented Apr 26, 2016

Going to test this

@laanwj

This comment has been minimized.

Show comment
Hide comment
@laanwj

laanwj Apr 26, 2016

Member

Not sure if this is expected behavior, it's probably harmless; but during the "Reindexing block file" initial scan, rev*.dat files are created with size 0:

-rw------- 1 user user         0 Apr 26 15:26 rev00415.dat
-rw------- 1 user user         0 Apr 26 15:26 rev00416.dat
-rw------- 1 user user         0 Apr 26 15:26 rev00417.dat
-rw------- 1 user user         0 Apr 26 15:26 rev00418.dat

Edit: the block counts are off? possibly due to out-of-order blocks not being counted. It looks a bit strange but probably harmless:

2016-04-26 13:30:48 Reindexing block file blk00471.dat...
2016-04-26 13:30:51 Loaded 3 blocks from external file in 2585ms
Member

laanwj commented Apr 26, 2016

Not sure if this is expected behavior, it's probably harmless; but during the "Reindexing block file" initial scan, rev*.dat files are created with size 0:

-rw------- 1 user user         0 Apr 26 15:26 rev00415.dat
-rw------- 1 user user         0 Apr 26 15:26 rev00416.dat
-rw------- 1 user user         0 Apr 26 15:26 rev00417.dat
-rw------- 1 user user         0 Apr 26 15:26 rev00418.dat

Edit: the block counts are off? possibly due to out-of-order blocks not being counted. It looks a bit strange but probably harmless:

2016-04-26 13:30:48 Reindexing block file blk00471.dat...
2016-04-26 13:30:51 Loaded 3 blocks from external file in 2585ms
@laanwj

This comment has been minimized.

Show comment
Hide comment
@laanwj

laanwj Apr 26, 2016

Member

Did a reindex of my test chain using this patch:

2016-04-26 13:07:36 Reindexing block file blk00000.dat...
2016-04-26 13:32:16 UpdateTip: new best=00000000839a8e6886ab5951d76f411475428afc90947ee320161bbf18eb6048 height=1 version=0x00000001 log2_work=33.000022 tx=2 date='2009-01-09 02:54:25' progress=0.000000 cache=0.0MiB(1tx)
2016-04-26 17:44:18 UpdateTip: new best=00000000000000000360e6d03330560950285d1062c6f6e6a4558ba1720d6e73 height=407838 version=0x00000004 log2_work=84.507935 tx=123156514 date='2016-04-18 11:34:09' progress=0.994753 cache=43.8MiB(23470tx)

Times:

phase1   00:24:40 (1480s)
phase2   04:12:02 (15122s)
         -----------------
total    04:36:42 (16602s)

For comparison, a sync from a local node on the same machine, under the same conditions, takes 05:32:29 (19949s). That's very good. I have not tried doing a 'traditional' reindex,

Edit: also verified that this fixes #7038. Also tested that interrupting the reindex then restarting works, both in the first phase and second phase.

Edit.2: also did a "traditional" reindex - it took 04:45:49 (17149s). Only a bit longer. Note that this is a fast CPU with 8 cores, so possibly the difference with not validating is less than it would otherwise be.

Edit.3: verified that utxo set hash is the same after old reindex versus new reindex (just to be sure).

Member

laanwj commented Apr 26, 2016

Did a reindex of my test chain using this patch:

2016-04-26 13:07:36 Reindexing block file blk00000.dat...
2016-04-26 13:32:16 UpdateTip: new best=00000000839a8e6886ab5951d76f411475428afc90947ee320161bbf18eb6048 height=1 version=0x00000001 log2_work=33.000022 tx=2 date='2009-01-09 02:54:25' progress=0.000000 cache=0.0MiB(1tx)
2016-04-26 17:44:18 UpdateTip: new best=00000000000000000360e6d03330560950285d1062c6f6e6a4558ba1720d6e73 height=407838 version=0x00000004 log2_work=84.507935 tx=123156514 date='2016-04-18 11:34:09' progress=0.994753 cache=43.8MiB(23470tx)

Times:

phase1   00:24:40 (1480s)
phase2   04:12:02 (15122s)
         -----------------
total    04:36:42 (16602s)

For comparison, a sync from a local node on the same machine, under the same conditions, takes 05:32:29 (19949s). That's very good. I have not tried doing a 'traditional' reindex,

Edit: also verified that this fixes #7038. Also tested that interrupting the reindex then restarting works, both in the first phase and second phase.

Edit.2: also did a "traditional" reindex - it took 04:45:49 (17149s). Only a bit longer. Note that this is a fast CPU with 8 cores, so possibly the difference with not validating is less than it would otherwise be.

Edit.3: verified that utxo set hash is the same after old reindex versus new reindex (just to be sure).

@laanwj

View changes

Show outdated Hide outdated src/init.cpp
@jonasschnelli

This comment has been minimized.

Show comment
Hide comment
@jonasschnelli

jonasschnelli Apr 28, 2016

Member

Tested on a mainnet node:

jonasschnelli@bitcoinsrv:~/.bitcoin$ cat debug.log | grep "Bitcoin version\|Reindexing finished\|height=409149"
2016-04-27 14:11:51 Bitcoin version v0.12.99.0-fb682d7 (2016-04-27 15:34:26 +0200)
2016-04-27 14:34:17 Reindexing finished
2016-04-27 18:52:50 UpdateTip: new best=000000000000000000c2963b062bebef4beff8ef38ae5d81e7ccfa8e05abcb1a height=409149 version=0x00000004 log2_work=84.559763 tx=125119626 date='2016-04-27 14:05:06' progress=0.999875 cache=4.0MiB(0tx)

= Times:

phase1    1'346s (00:22:26)
phase2   15'513s (04:18:33)
===========================
total    16'859s (04:40:59)

Full debug log with -debug=reindex http://bitcoinsrv.jonasschnelli.ch/debug.reindex.log (>240MB!)

Member

jonasschnelli commented Apr 28, 2016

Tested on a mainnet node:

jonasschnelli@bitcoinsrv:~/.bitcoin$ cat debug.log | grep "Bitcoin version\|Reindexing finished\|height=409149"
2016-04-27 14:11:51 Bitcoin version v0.12.99.0-fb682d7 (2016-04-27 15:34:26 +0200)
2016-04-27 14:34:17 Reindexing finished
2016-04-27 18:52:50 UpdateTip: new best=000000000000000000c2963b062bebef4beff8ef38ae5d81e7ccfa8e05abcb1a height=409149 version=0x00000004 log2_work=84.559763 tx=125119626 date='2016-04-27 14:05:06' progress=0.999875 cache=4.0MiB(0tx)

= Times:

phase1    1'346s (00:22:26)
phase2   15'513s (04:18:33)
===========================
total    16'859s (04:40:59)

Full debug log with -debug=reindex http://bitcoinsrv.jonasschnelli.ch/debug.reindex.log (>240MB!)

@sipa

This comment has been minimized.

Show comment
Hide comment
@sipa

sipa Apr 28, 2016

Member

Added GUI progress reporting

Member

sipa commented Apr 28, 2016

Added GUI progress reporting

@sipa

This comment has been minimized.

Show comment
Hide comment
@sipa

sipa May 1, 2016

Member

The two phases in the GUI:

reindexing
processing

If the chainstate is ahead of the block index at startup, you get the same "Processing blocks on disk" now, while the main GUI is running (and not during loading).

Member

sipa commented May 1, 2016

The two phases in the GUI:

reindexing
processing

If the chainstate is ahead of the block index at startup, you get the same "Processing blocks on disk" now, while the main GUI is running (and not during loading).

@laanwj

This comment has been minimized.

Show comment
Hide comment
@laanwj

laanwj May 2, 2016

Member

@sipa Very nice!

Member

laanwj commented May 2, 2016

@sipa Very nice!

@jonasschnelli

This comment has been minimized.

Show comment
Hide comment
@jonasschnelli

jonasschnelli May 2, 2016

Member

Just started to sync with master+thisPR a new node over the GUI on Ubuntu 16.04 with dbcache=3500 and got this:

bildschirmfoto 2016-05-02 um 15 41 44

The GUI used chainActive.tip(). Is this no longer updated continuously?

Member

jonasschnelli commented May 2, 2016

Just started to sync with master+thisPR a new node over the GUI on Ubuntu 16.04 with dbcache=3500 and got this:

bildschirmfoto 2016-05-02 um 15 41 44

The GUI used chainActive.tip(). Is this no longer updated continuously?

@sipa

This comment has been minimized.

Show comment
Hide comment
@sipa

sipa May 5, 2016

Member

@jonasschnelli I added another commit that hopefully fixes that (untested).

Member

sipa commented May 5, 2016

@jonasschnelli I added another commit that hopefully fixes that (untested).

@sipa

This comment has been minimized.

Show comment
Hide comment
@sipa

sipa May 9, 2016

Member

Rebased.

Member

sipa commented May 9, 2016

Rebased.

@jonasschnelli

This comment has been minimized.

Show comment
Hide comment
@jonasschnelli

jonasschnelli May 10, 2016

Member

Just started a Qt reindex with https://bitcoin.jonasschnelli.ch/pulls/7917/ (7ac4114).
The debug window shows 0 as current number of blocks (is this intentional?).
The progress bar in the main window is updating.

bildschirmfoto 2016-05-10 um 09 52 04

Member

jonasschnelli commented May 10, 2016

Just started a Qt reindex with https://bitcoin.jonasschnelli.ch/pulls/7917/ (7ac4114).
The debug window shows 0 as current number of blocks (is this intentional?).
The progress bar in the main window is updating.

bildschirmfoto 2016-05-10 um 09 52 04

@laanwj

This comment has been minimized.

Show comment
Hide comment
@laanwj

laanwj May 10, 2016

Member

Hm but I see the same behavior, reindexing a regtest chain.
Log shows:

2016-05-10 09:53:32 UpdateTip: new best=57d8789c33ee61db98c8b87076cae5c637056bff4a4c340b3ef28e9bc853a4a3 height=250 version=0x00000003 log2_work=8.9715436 tx=251 date='2015-06-23 12:20:30' progress=1.000000 cache=0.1MiB(250tx)

While the current number of blocks in the debug window is still at 1.
Same for the onmouseover "Processed 1 block of transaction history"

Member

laanwj commented May 10, 2016

Hm but I see the same behavior, reindexing a regtest chain.
Log shows:

2016-05-10 09:53:32 UpdateTip: new best=57d8789c33ee61db98c8b87076cae5c637056bff4a4c340b3ef28e9bc853a4a3 height=250 version=0x00000003 log2_work=8.9715436 tx=251 date='2015-06-23 12:20:30' progress=1.000000 cache=0.1MiB(250tx)

While the current number of blocks in the debug window is still at 1.
Same for the onmouseover "Processed 1 block of transaction history"

@laanwj

This comment has been minimized.

Show comment
Hide comment
@laanwj

laanwj May 10, 2016

Member

In my case it is a problem is in the rate limiting in BlockTipChanged.
If the updating goes too fast, it will only send a signal for the initial value.

if (!initialSync || now - nLastBlockTipUpdateNotification > MODEL_UPDATE_DELAY) {

This is not new in this patch, just exposed by the new syncing behavior. I think we should move ahead with this and solve the UI issues separately.

Member

laanwj commented May 10, 2016

In my case it is a problem is in the rate limiting in BlockTipChanged.
If the updating goes too fast, it will only send a signal for the initial value.

if (!initialSync || now - nLastBlockTipUpdateNotification > MODEL_UPDATE_DELAY) {

This is not new in this patch, just exposed by the new syncing behavior. I think we should move ahead with this and solve the UI issues separately.

@sipa

This comment has been minimized.

Show comment
Hide comment
@sipa

sipa May 15, 2016

Member

@laanwj @jonasschnelli Added another commit to make header updates not compete for rate limiting with block updates.

Member

sipa commented May 15, 2016

@laanwj @jonasschnelli Added another commit to make header updates not compete for rate limiting with block updates.

@@ -4060,17 +4102,19 @@ bool LoadExternalBlockFile(const CChainParams& chainparams, FILE* fileIn, CDiskB
std::multimap<uint256, CDiskBlockPos>::iterator it = range.first;
if (ReadBlockFromDisk(block, it->second, chainparams.GetConsensus()))
{
LogPrintf("%s: Processing out of order child %s of %s\n", __func__, block.GetHash().ToString(),
LogPrint("reindex", "%s: Processing out of order child %s of %s\n", __func__, block.GetHash().ToString(),

This comment has been minimized.

@MarcoFalke

MarcoFalke May 16, 2016

Member

Does this require mention in the -debug=<category> help text?

@MarcoFalke

MarcoFalke May 16, 2016

Member

Does this require mention in the -debug=<category> help text?

This comment has been minimized.

@sipa

sipa May 16, 2016

Member

Agree!

@sipa

sipa May 16, 2016

Member

Agree!

@sipa

This comment has been minimized.

Show comment
Hide comment
@sipa

sipa May 16, 2016

Member

Squashed and rebased.

Member

sipa commented May 16, 2016

Squashed and rebased.

@pstratem

This comment has been minimized.

Show comment
Hide comment
@pstratem

pstratem May 17, 2016

Contributor

utACK fb8fad1

Contributor

pstratem commented May 17, 2016

utACK fb8fad1

@pstratem

This comment has been minimized.

Show comment
Hide comment
@pstratem

pstratem May 17, 2016

Contributor

utACK d3d7547

Contributor

pstratem commented May 17, 2016

utACK d3d7547

@pstratem

This comment has been minimized.

Show comment
Hide comment
@pstratem

pstratem May 17, 2016

Contributor

very untested ACK b4d24e1 (sanity not guaranteed)

Contributor

pstratem commented May 17, 2016

very untested ACK b4d24e1 (sanity not guaranteed)

@pstratem

This comment has been minimized.

Show comment
Hide comment
@pstratem

pstratem May 17, 2016

Contributor

On a related note access to chainActive immediately after threadGroup.create_thread(boost::bind(&ThreadImport, vImportFiles)); is not protected by cs_main

Contributor

pstratem commented May 17, 2016

On a related note access to chainActive immediately after threadGroup.create_thread(boost::bind(&ThreadImport, vImportFiles)); is not protected by cs_main

@laanwj laanwj merged commit b4d24e1 into bitcoin:master May 18, 2016

1 check passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details

laanwj added a commit that referenced this pull request May 18, 2016

Merge #7917: Optimize reindex
b4d24e1 Report reindexing progress in GUI (Pieter Wuille)
d3d7547 Add -reindex-chainstate that does not rebuild block index (Pieter Wuille)
fb8fad1 Optimize ActivateBestChain for long chains (Pieter Wuille)
316623f Switch reindexing to AcceptBlock in-loop and ActivateBestChain afterwards (Pieter Wuille)
d253ec4 Make ProcessNewBlock dbp const and update comment (Pieter Wuille)

@MarcoFalke MarcoFalke referenced this pull request May 22, 2016

Closed

TODO for release notes 0.13.0 #7678

14 of 16 tasks complete

@dgenr8 dgenr8 referenced this pull request Jan 15, 2017

Merged

Optimize reindex #186

str4d added a commit to str4d/zcash that referenced this pull request Feb 23, 2017

sickpig referenced this pull request in sickpig/BitcoinUnlimited Mar 4, 2017

Merge #7917: Optimize reindex
b4d24e1 Report reindexing progress in GUI (Pieter Wuille)
d3d7547 Add -reindex-chainstate that does not rebuild block index (Pieter Wuille)
fb8fad1 Optimize ActivateBestChain for long chains (Pieter Wuille)
316623f Switch reindexing to AcceptBlock in-loop and ActivateBestChain afterwards (Pieter Wuille)
d253ec4 Make ProcessNewBlock dbp const and update comment (Pieter Wuille)

@OlegGirko OlegGirko referenced this pull request Jul 9, 2017

Merged

Backport Bitcoin PR#7917: Optimize reindex #1515

1 of 1 task complete
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment