Other SQLite restrictions/limitations/issues that are removed with BDB?
In Berkeley DB, PRAGMA synchronous has a different meaning to SQLite. In SQLite, with levels lower than FULL, databases may be corrupted after a failure. In Berkeley DB, databases can always be recovered to a consistent state, because write-ahead logging semantics are always enforced on the Berkeley DB log. So the synchronous setting can improve throughput in Berkeley DB without risking corruption. The synchronous=ON level in Berkeley DB is equivalent to the DB_TXN_WRITENOSYNC flag and implies that transactions committed before a system crash (such as a hard reboot or power loss) may be rolled back on recovery. Application crashes do not cause committed transactions to be rolled back at this level. The synchronous=OFF level is equivalent to the DB_TXN_NOSYNC flag and implies that committed transactions may be rolled back after either an application or a system crash.
Related Questions
- Does SQLite re-use deleted space on a page in the same way that BDB does (using the Btree key to determine which page the data should be stored on)?
- SQLite data types are documented here, but what are the important implications and how does it affect the BDB integration?
- Can a Bella Sol tan be removed?
