git master HEAD causes v0.8.6 to fail to open the block database #3529

Running a version built from Git (I happen to be using a gitian-build, win32, at commit 549e69a558a045829d2910c5d172e91f49101a31) seems to do something to the database that causes v0.8.6 to report an error opening the block database, requiring a reindex.

Reproduced here, also.

Okay, just got through my first ever git bisect...

35ecf854c084c248ad640c6af030a9d1ed726c47 is the first bad commit commit 35ecf854c084c248ad640c6af030a9d1ed726c47 Author: Wladimir J. van der Laan laanwj@gmail.com Date: Wed Jan 8 08:59:24 2014 +0100

qt: Remove global references in bitcoin.cpp

Remove the need for global references `guiref` and
`splashref` by making the BitcoinGUI and SplashScreen
classes register for the UI interface signals themselves.

:040000 040000 b409b02f0e01d640169733ed046a326cf79d48c2 a2a221172cc733ff63ce08f800164538e912fdb0 M src

EDIT: Okay, either I messed up the bisection, or there's something non-deterministic in play, because I first noticed the problem on an earlier commit.

@laanwj?

@sipa This is the index incompatibility that I ran into yesterday. See above for cause.

I don't see a cause.

Could this be caused by the difference in leveldb version? (1.15+patches versus 1.13+patches)

@laanwj Confirmed, backing down master to leveldb-1.13 as shipped in v0.8.6 allows the index to be compatible.

Ok, so leveldb 1.14 is not backward compatible with older versions because... they changed their file naming scheme.

Leveldb 1.13 and below, write to (and read from) NNNNNN.sst files for compacted table. Labeldb 1.14 and up, write to NNNNNN.ldb (but also try reading from NNNNNN.sst).

There are 3 options, I think:

• Downgrade to 1.13 (with OSX fixes) again, and stay there until... who knows.
• Patch the 1.15 source code to write to .sst again (it's a 1 line change, @wtogami tested it already).
• Just accept that running 0.9 will make your databases incompatible with 0.8.x and before (though trivially repairable, just rename the files).

It's silly that we need to worry about compatibility for such a bikeshed issue, but it will cause problems...

I vote patch 1.15 for sst, and make the breaking change when we implement pruning (since that will also break/confuse 0.8)

Is it possible to detect and do the trivially repair on install?

@cabbiepete Sure, but that would be a lot more work than 1-line patch! @luke-jr ACK

@sipa Of course but at some point we need the process to be transparent, seamless, no brainer for users otherwise we make less wise people feel uncomfortable and less and less likely to run bitcoin-qt for a client and all that goes with it. If you guys feel its not time for that np just wanted to put it out there :-) Also if we would prefer that but don't have resource maybe I can help installer scripts can't be that hard to work out maybe even I can do it.

@sipa on closer inspection I guess the patch provides the same benefits, with only downside being maintenance of the patch.

ACK on write the old name read the old and new. We'll have to make a backwards incompatible change at some point and we can stop carrying the patch then.

also ACK on write the old name read the old and new.

This is fixed now that sipa's leveldb change has been merged.