On 09/18/2015 11:42 AM, Leonardo Sandoval wrote:
On 09/17/2015 03:01 PM, Burton, Ross wrote:
On 15 September 2015 at 15:59,
<leonardo.sandoval.gonza...@linux.intel.com>
wrote:
- self.connection.execute("PRAGMA journal_mode = WAL;")
+ self.connection.execute("PRAGMA journal_mode = DELETE;")
Richard probably has a better memory than me but I seem to recall that
WAL
was a pretty serious speed improvement for the local host case. Did you
benchmark the impact this change has?
Unfortunately, I didn't do any benchmark.
The problem with WAL is the following "All processes using a database
must be on the same host computer; WAL does not work over a network
filesystem." Using WAL, all PR values get lost after a PR server reboot,
so we need a rollback journal. According to the documentation, the
fastest of the these is "MEMORY" but it has its pros/cons:
"The MEMORY journaling mode stores the rollback journal in volatile RAM.
This saves disk I/O but at the expense of database safety and integrity.
If the application using SQLite crashes in the middle of a transaction
when the MEMORY journaling mode is set, then the database file will very
likely go corrupt."
Ross: ignore my comment. The limitation "all process using a database
must be on the same host" is not a limitation for us, because the
PRserver is the only one talking to the database and this daemon/process
is at the same place as the DB. So the root reason why WAL is not
working is still unknown. Sending a V2 soon.
Ross
--
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
