[sql] Database recovery system for Shortcuts.

tools/metrics/histograms/histograms.xml

Index: tools/metrics/histograms/histograms.xml
diff --git a/tools/metrics/histograms/histograms.xml b/tools/metrics/histograms/histograms.xml
index 15640b6d239fa3822485a1180c683604fbe932d7..8320c31d5c49756331a76b0c36e4b680a76be518 100644
--- a/tools/metrics/histograms/histograms.xml
+++ b/tools/metrics/histograms/histograms.xml
@@ -81879,6 +81879,33 @@ To add a new entry, add it with any value and run test to compute valid value.
   <int value="19" label="RECOVERY_FAILED_META_NO_VERSION">
     GetMetaVersionNumber() found no version row in meta table.
   </int>
+  <int value="20" label="RECOVERY_SUCCESS_AUTORECOVERDB">
+    sql::Recovery::RecoverDatabaseOrRaze() completed successfully.
+  </int>
+  <int value="21" label="RECOVERY_FAILED_AUTORECOVERDB_BEGIN">
+    In autorecover database was too broken to begin.

[Mark P, 2016/04/07 23:09:44]

optional nit (has better emphasis in my opinion):
Database was too broken to attempt recovery.

[Scott Hess - ex-Googler, 2016/04/15 00:38:16]

Done.

+  </int>
+  <int value="22" label="RECOVERY_FAILED_AUTORECOVERDB_SCHEMA">
+    Autorecover could not copy existing schema.
+  </int>
+  <int value="23" label="RECOVERY_FAILED_AUTORECOVERDB_SCHEMACREATE">
+    Autorecover could not create new db schema.

[Mark P, 2016/04/08 20:12:07]

Consider mentioning this is a subset of RECOVERY_FAILED_AUTORECOVERDB_SCHEMA.
ditto below.
That said, I see you have weird subset relationships elsewhere in this enum.  I
wonder if mentioning this in some places but not others (unless you want to make
this list complete) somewhat confusing.
Maybe you should simply add something to the histogram description.

[Scott Hess - ex-Googler, 2016/04/15 00:38:16]

It's intended to be more like code coverage, where I'm tracking which decision
points were taken.  Being able to add things up is only weakly useful, mostly
everything other than SUCCESS should normalize against SUCCESS.  The only reason
I'd care if one failure case was greater than another is in prioritizing which
to look at first.

+  </int>
+  <int value="24" label="RECOVERY_FAILED_AUTORECOVERDB_SCHEMASELECT">
+    Autorecover could not read corrupt db schema.
+  </int>
+  <int value="25" label="RECOVERY_FAILED_AUTORECOVERDB_NAMESELECT">
+    Autorecover could not read table names to copy.
+  </int>
+  <int value="26" label="RECOVERY_FAILED_AUTORECOVERDB_TABLE">
+    Autorecover failed recovering a table.

[Mark P, 2016/04/07 23:09:44]

For something like this, which is probably a more common type of recovery
failure, do you want to record the failed type of error code in another
histogram?  (or extra values within this histogram I suppose)

[Scott Hess - ex-Googler, 2016/04/15 00:38:16]

My approach was since I already have this histogram to track flow of control,
I'll hit all of those points since it's "free".  Then if any failure cases seem
bothersome, I'll circle back and add something to debug those.

Mostly I'm just being lazy, and somewhat trying to avoid analysis paralysis. 
Most of the failure points in AutorecoverTable() shouldn't be possible, because
it's operating against a temporary database, and, indeed, the histograms show
low occurance in there.  I guess SQLITE_IOERR or SQLITE_FULL could happen, and
in either case it's kind of a give-up situation.  RECOVERY_FAILED_ATTACH fails
enough that logging that error code may make sense before flipping that case to
raze.

+  </int>
+  <int value="27" label="RECOVERY_FAILED_AUTORECOVERDB_SEQUENCE">
+    Autorecover failed recovering sequence table.
+  </int>
+  <int value="28" label="RECOVERY_FAILED_AUTORECOVERDB_AUX">
+    Autorecover failed recovering triggers, views, or virtual tables.
+  </int>
 </enum>
 
 <enum name="SqliteStatsEnum" type="int">