Index: sql/recovery.h |
diff --git a/sql/recovery.h b/sql/recovery.h |
index af99108192908593db1ef4844086324609f35a2b..9ff2bed3abccafb9aff5f302f45cae6432416398 100644 |
--- a/sql/recovery.h |
+++ b/sql/recovery.h |
@@ -149,6 +149,44 @@ class SQL_EXPORT Recovery { |
// Only valid to call after successful SetupMeta(). |
bool GetMetaVersionNumber(int* version_number); |
+ // Attempt to recover the database by creating a new database with schema from |
+ // |db|, then copying over as much data as possible. If the database is |
+ // entirely unreadable, the new database will be empty. After this call, the |
+ // |db| handle will be poisoned so that future calls will return errors until |
+ // the handle is re-opened. |
+ // |
+ // The "OrRaze" portion means that if recovery fails due to errors, the |
+ // database can be razed or deleted. The goal is for this function to make |
Mark P
2016/04/07 23:09:44
Uh, did you mean "will be", not "can be"? And wil
Scott Hess - ex-Googler
2016/04/15 00:38:15
I'm not sure how to answer!
Right now, it only ap
|
+ // every possible effort to leave behind a correctly operating database file. |
+ static void RecoverDatabaseOrRaze(Connection* db, |
+ const base::FilePath& db_path); |
+ |
+ // Returns true if the SQLite |extended_error| is one which can plausibly be |
+ // recovered, or which cannot possibly be recovered. |
+ // |
Mark P
2016/04/07 23:09:44
Please provide an transition sentence here. It ap
Scott Hess - ex-Googler
2016/04/15 00:38:15
Moved cases into the implementation file.
I'm not
|
+ // SQLITE_CANTOPEN is associated with an entirely broken file (for instance a |
+ // symlink to a non-existent path, or the file is a directory). The best fix |
+ // is probably to delete the file and start over. |
Mark P
2016/04/07 23:09:44
probably?
When this is not the best fix?
(consider
Scott Hess - ex-Googler
2016/04/15 00:38:15
I guess this is expressing my certainty level. SQ
|
+ // |
+ // SQLITE_NOTADB can happen if the SQLite header is broken. In earlier |
+ // versions of SQLite, this was returned if the header size information did |
+ // not match the OS file size information (now that causes SQLITE_CORRUPT). |
+ // In that case much of the data can be recovered. In other cases, the best |
+ // fix is probably to delete the file and start over. |
Mark P
2016/04/07 23:09:44
This last sentence is confusing. Did you mean tha
Scott Hess - ex-Googler
2016/04/15 00:38:15
When the recovery code was first written, there wa
|
+ // |
+ // SQLITE_CORRUPT means that the database is readable, but the contents have |
+ // an inconsistency. In the worst case, this could be isolated garbage in a |
+ // page, but generally it means that pages which are separately valid do not |
+ // make sense when taken together. For instance if an index refers to a row |
+ // which is no longer in the table. |
Mark P
2016/04/07 23:09:44
Again, this explanation doesn't state what this fu
Scott Hess - ex-Googler
2016/04/15 00:38:15
Revised in implementation.
|
+ // |
+ // TODO(shess): Possible future options for automated fixing: |
+ // - SQLITE_PERM - permissions could be fixed. |
+ // - SQLITE_READONLY - permissions could be fixed. |
+ // - SQLITE_IOERR - rewrite using new blocks. |
+ // - SQLITE_FULL - recover in memory and rewrite subset of data. |
+ static bool ShouldRecoverOrRaze(int extended_error); |
Mark P
2016/04/07 23:09:44
nit: given your explanation of what this does, I t
Scott Hess - ex-Googler
2016/04/15 00:38:15
Hmm. None of the first three work with me - there
|
+ |
private: |
explicit Recovery(Connection* connection); |