Is the other instance you refer to if the saved blockchain is more recent that the lmdb database (which I'm not sure how that would happen in practice unless you copied a newer blockchain.bin where there's an older db), or are you talking about something else?
Just in general that the process isn't transnational the way an ACID database commit normally would be so things can go wrong in various ways. Without carefully auditing the ordering of events and the behavior of various operating systems it is hard to be 100% sure what failure modes are possible.
For example, another failure that occasionally happens on Windows (for all cryptonotes) is the blockchain.bin file gets corrupted during save since there isn't a really good way to replace a file atomically (on Linux you can rename-replace, which mostly works). This would leave you with a valid database but an invalid blockchain.bin. Of course this would probably be no worse than the previous (no db) case, but would be worse than the full db case. This is fixable, but somewhat annoying to fix, especially if all the data is going to end up in a database eventually anyway (I have no idea as to your plans).
BTW, in case my comments were not clear I do think this is nice work by crypto_zoidberg and clintar.
Ok, thanks for the input. Just wondered if there was something I should be looking into I hadn't thought of. I don't really know the plans, either. Just was contributing what I came up with as a work-around. I agree having everything in the database does take care if these issues, too. Pretty slick how cz implemented the db, though, huh? At least I thought so. Anyone have any suggestions for things they want to see in the codebase?