This gives us a ~60% win in execution time per operation on the async thread, over trunk. Compared to journal_mode = TRUNCATE, it's about 40%.

-> Future, since we can't take this for 2.0 since we're not upgrading sqlite on 1.9.2 which means dataloss for people migrating backward.

OK, turns out we srsly need this for betaN, otherwise opening an unshared connection for synchronous ops can fail.

Comment on attachment 476957 [details] [diff] [review] patch >+ rv = mDBState->dbConn->ExecuteSimpleSQL(NS_LITERAL_CSTRING("PRAGMA journal_mode = WAL")); >+ NS_WARN_IF_FALSE(NS_SUCCEEDED(rv), "couldn't set journal_mode = WAL"); Don't think this would actually fail. The only way you'd know it's not WAL is by seeing what is returned by PRAGMA journal_mode, but you probably don't care. r=sdwilsh

Possible that this is causing cookie failure when restarting the browser and you find that your logged out of forums?

Is this waiting on anything to land?

Yes -- it's in my queue along with 599799 and 591447.

http://www.sqlite.org/draft/wal.html says that WAL requires a non-networked database location, which we must support for roaming profiles.

sdwilsh sayeth that it's OK; we have the profile lock and access occurs through a single process.

(In reply to comment #8) > http://www.sqlite.org/draft/wal.html says that WAL requires a non-networked > database location, which we must support for roaming profiles. More specifically, it says: All processes using a database must be on the same host computer; WAL does not work over a network filesystem. This doesn't work over a networked file system because it cannot use shared memory on different machines. However, if our access is on the same machine, I'm told we are fine.

Could this have caused bug 605835?