-
Notifications
You must be signed in to change notification settings - Fork 296
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
blockchain: Remove incorrect upgrade version check. #3010
Conversation
JoeGruffins
commented
Oct 12, 2022
•
edited
Loading
edited
I'm not sure if this is correct. If there is a db but no dbinfo it`s correct, but if the db is completely new, then you want the current version. It should do based on blockDBVersion maybe? |
88f3b03
to
7a84fe1
Compare
What comes of a DB that has run the upgrades already without this diff? Busted? |
I think I am wrong about when the version info was added. It's actually 9 99259dc
The utxo db would be version three (or already two) without having run the update from 1 -> 2 -> 3. For some reason, the 1 -> 2 update not happening doesn't seem to break us, but the 2 -> 3 does. Our blockDBVersion in dcrdex looks to be version 7. The affected db is broken unless the update is run apparently. If the 1 -> 2 was missed I'm not sure what the implications are. This would be hard to diagnose for the user afaict. It looks like v1.7 has a currentUtxoDatabaseVersion of 2. So, a user with a blockDBVersion earlier than 9 would skip the 1 > 2 as well I guess. |
3cfa737
to
218d31f
Compare
I think the exact problem is that the old db will have all utxo in |
So, I think the answer is simpler than this. We just require |
Is it correct that |
Unrelated, but I see this message in logs a lot |
If utxo version is 2, ignore the utxo db version and upgrade. This ensures that old databases have the utxo data moved. Also move the utxo upgrade which uses the new version below so that it will find the new bucket.
218d31f
to
a511463
Compare
Yep, that is what I found last night as well when I was pointing out the commits in question. Hence why I said the culprit was introduced in 7780ad9 and then was manifest in d1b381d.
Yes, I dug through history and taking everything into consideration, all that needs to be done is move the For reference, what happened here is that originally the version 2 utxoset was put into the separate utxo database and upgraded to version 3 there, but in order to resolve some other issues (data that was needed for the spend journal), it was reversed such that the version 2 utxoset is upgraded to version 3 in the main database and then moved to the separate utxo database. In other words, because the version 2 to 3 utxoset upgrade is happening in the main database, the utxo database version is irrelevant and that is why checking it as part of the upgrade results in incorrect logic. |
This is known and isn't really a big issue. It is something that would be nice to address, but it doesn't really affect anything important. |