Nameindex.dat - Berkleydb - anyone familiar want to help?
Posted: Tue Jan 07, 2014 4:38 pm
p.s. not sure if this is the right place to post, or could even try bitcointalk dev board (although can be hostile if not related to btc 
)
any help could save a lot of time
Here is the problem :
If the client is forcefully terminated, blkindex.dat and nameindex.dat may get out-of-sync. After that, the chain will stick at the current block.
To fix, one has to delete nameindex.dat (it will then be automatically recreated on startup via rescan).
There are two ad-hoc solutions for this:
1) get rid of nameindex.dat and store it's contents in blkindex.dat, so the two will always be synced
2) store last block number in nameindex.dat and rescan last N blocks on startup (like done in wallet.dat)
However there should exist a simpler solution based on BDB transactions. CNameDB class has some functionality for this. The constructor accepts the parameter
CDB& parent
which is meant to make changes to two separate databases atomically. It is used like this:
It is supposed that the last commit/abort must keep CNameDB in sync too, but for some reason this functionality is broken.
Someone knowledgeful in BDB can probably spot the problem quite easily. There are three places to check:
1) is parent DB functionality implemented properly?
2) is it used properly (as per the code above)?
3) is it used everywhere it should be used (i.e. each time something is written to NameDB)?
)any help could save a lot of time
Here is the problem :
If the client is forcefully terminated, blkindex.dat and nameindex.dat may get out-of-sync. After that, the chain will stick at the current block.
To fix, one has to delete nameindex.dat (it will then be automatically recreated on startup via rescan).
There are two ad-hoc solutions for this:
1) get rid of nameindex.dat and store it's contents in blkindex.dat, so the two will always be synced
2) store last block number in nameindex.dat and rescan last N blocks on startup (like done in wallet.dat)
However there should exist a simpler solution based on BDB transactions. CNameDB class has some functionality for this. The constructor accepts the parameter
CDB& parent
which is meant to make changes to two separate databases atomically. It is used like this:
Code: Select all
txdb.TxnBegin();
...
// Process block
...
{
// Save names from block to name db
CNameDB dbName("cr+", txdb);
dbName.TxnBegin();
...
dbName.TxnCommit();
}
...
if (accept_block)
txdb.TxnCommit();
else
txdb.TxnAbort(); Someone knowledgeful in BDB can probably spot the problem quite easily. There are three places to check:
1) is parent DB functionality implemented properly?
2) is it used properly (as per the code above)?
3) is it used everywhere it should be used (i.e. each time something is written to NameDB)?
