There's an art to debugging with print statements. You need to show enough to be able to identify problems happening, without being so verbose as to overwhelm with useless noise. When #LMDB is built with debug logging enabled, the output can be too voluminous to sift thru.

But it shows exactly what the code is doing, in such a way that you can parse the log and rerun the exact same operations, and get an identical database as a result.

Reply to this note

Please Login to reply.

Discussion

We've relied on this property in the past, to prove to an installation that the database corruption they were experiencing wasn't an LMDB bug - it turned out to be a faulty DRAM DIMM in their server. Without LMDB's deterministic write behavior, convincing someone of these cases would be a lot more difficult.

But proving the presence of a bug and narrowing down its cause are really two different tasks, and thus requires two different types of logging.

In my old work colleague was big fan of such verbose logging. Few times it saved our asses.