Implement sql::Connection::Raze() in terms of sqlite3_backup API.

sql/connection.h

Index: sql/connection.h
diff --git a/sql/connection.h b/sql/connection.h
index 9b81804bc1fafb68bac8bfb9a63dff4c6887305c..1e3414f40ca72912b0b8e0b64af1fa37d5e78a1f 100644
--- a/sql/connection.h
+++ b/sql/connection.h
@@ -181,6 +181,26 @@ class SQL_EXPORT Connection {
   // generally exist either.
   void Preload();
 
+  // Raze the database to the ground.  This approximates creating a
+  // fresh database from scratch, within the constraints of SQLite's
+  // locking protocol (locks and open handles can make doing this with
+  // filesystem operations problematic).  Returns true if the database

[Greg Billock, 2012/03/31 01:23:50]

Does this mean it won't necessarily work? It seems like this would be used in
extreme situations, so wouldn't that mean it should take steps to try to make
sure that collisions get nuked as well?

[Scott Hess - ex-Googler, 2012/04/04 01:28:25]

My broad background with this change is:
A) corruption isn't that common in the first place, and has varied causes, which
make this hard to test for real.
B) we have a baseline presumption that SQLite's core operations like opening
journal files and writing pages are appropriate.

Tracing through the SQLite code, there are places where this code can fall down,
and for the most part resolving the problem in those cases probably requires
changes in the caller, or additional gruntwork to track down what's really
happening (by adding histograms or DumpWithoutCrash() calls or something).  So
this CL aims to provide a best-effort, I-think-this-should-work-well starting
point, which can be built on.

My expectation is that we'll find that this doesn't work in a tiny number of
cases, and that they'll be "I have no idea what we can do about that" types of
cases.  Like "profile not writable" or "disk is horribly hosed".  If there's a
systemic case, like Database X turns out to have two writers instead of the
expected one, then we'll (hopefully) notice and drill down and fix the problem.

[Greg Billock, 2012/04/04 19:49:21]

Sounds good. I don't know if any of that's worth mentioning in the comment.
Since you've already written it, perhaps so...

On 2012/04/04 01:28:25, shess wrote:

+  // was razed.
+  //
+  // false is returned if the database is locked by some other
+  // process.  RazeWithTimeout() may be used if appropriate.

[Greg Billock, 2012/03/31 01:23:50]

What's the use case for that kind of call?

[Scott Hess - ex-Googler, 2012/04/04 01:28:25]

Most (all?) profile databases are exclusive-access, so they should NEVER receive
SQLITE_BUSY and Raze() should work.  Web SQL databases can be opened in multiple
renderers, in which case SQLITE_BUSY must be expected and handled.

[Greg Billock, 2012/04/04 19:49:21]

Do you envision using this most typically for WebSQL disaster recovery? My
mental image was this was for profile DBs, but perhaps that's completely off.

On 2012/04/04 01:28:25, shess wrote:

[Scott Hess - ex-Googler, 2012/04/04 20:28:52]

Mostly it's for profile dbs, but I believe websql has a case where the database
needs to be deleted, except there they don't have exclusive access so they have
to wait around for things to clear.  In the Gears days we had a similar problem,
where many processes could have connections, so it was unclear what to do when
corruption was detected.  We added sqlite3_poison() which broke the database in
a transactional fashion, so that on next access all the other connections broke
and reset.

+  //
+  // NOTE(shess): Raze() will DCHECK in the following situations:
+  // - database is not open.
+  // - the connection has a transaction open.
+  // - a SQLite issue occurs which is structural in nature (like the
+  //   statements used are broken).
+  // Since Raze() is expected to be called in unexpected situations,
+  // these all return false, since it is unlikely that the caller
+  // could fix them.
+  bool Raze();
+  bool RazeWithTimout(base::TimeDelta timeout);
+
   // Transactions --------------------------------------------------------------
 
   // Transaction management. We maintain a virtual transaction stack to emulate