>> Is it possible to use the CLI to read a WAL database and exit without >> modifying the database? >> >The checkpoint-on-close feature is not affected by >PRAGMA wal_autocheckpoint. The NO_CKPT_ON_CLOSE DB config flag is the >only mechanism to prevent it from inside the connection.
SQLITE_API int sqlite3_db_config(sqlite3 *db, int op, ...){ ... { SQLITE_DBCONFIG_NO_CKPT_ON_CLOSE, SQLITE_NoCkptOnClose }, and SQLITE_PRIVATE int sqlite3PagerClose(Pager *pPager, sqlite3 *db){ u8 *pTmp = (u8 *)pPager->pTmpSpace; ... sqlite3WalClose(pPager->pWal, db, pPager->ckptSyncFlags, pPager->pageSize, (db && (db->flags & SQLITE_NoCkptOnClose) ? 0 : pTmp) ); abd SQLITE_PRIVATE int sqlite3WalClose( Wal *pWal, /* Wal to close */ sqlite3 *db, /* For interrupt flag */ int sync_flags, /* Flags to pass to OsSync() (or 0) */ int nBuf, u8 *zBuf /* Buffer of at least nBuf bytes */ ){ int rc = SQLITE_OK; if( pWal ){ int isDelete = 0; /* True to unlink wal and wal-index files */ /* If an EXCLUSIVE lock can be obtained on the database file (using the ** ordinary, rollback-mode locking methods, this guarantees that the ** connection associated with this log file is the only connection to ** the database. In this case checkpoint the database and unlink both ** the wal and wal-index files. ** ** The EXCLUSIVE lock is not released before returning. */ if( zBuf!=0 && SQLITE_OK==(rc = sqlite3OsLock(pWal->pDbFd, SQLITE_LOCK_EXCLUSIVE)) ){ ...checkpointy goodness... } walIndexClose(pWal, isDelete); sqlite3OsClose(pWal->pWalFd); if( isDelete ){ sqlite3BeginBenignMalloc(); sqlite3OsDelete(pWal->pVfs, pWal->zWalName, 0); sqlite3EndBenignMalloc(); } WALTRACE(("WAL%p: closed\n", pWal)); sqlite3_free((void *)pWal->apWiData); sqlite3_free(pWal); } return rc; } If checkpoint-on-close is disabled, sqlite3WalClose(...,zBuf=null) which skips doing the checkpoint. This gives me the behavior I want. I just have no way of doing this via the CLI I was pawing through various corrupted databases. What I *want* is sqlite3 my.db sqlite> PRAGMA checkpoint_on_close=0; sqlite> PRAGMA integrity_check; ... sqlite> PRAGMA user_version; ... sqlite> .q and have the filesystem in the same state as when as I started. Since the CLI can't set that, I had to COPY THE DB before I touched it If the CLI could disable checkpoint-on-close it would have saved me a bunch of time I don't need the db to be physically readonly (and that's not possible for WAL), but disabling checkpoint-on-close does it for me. I can issue readonly commands, but SQLite's default checkpoint-on-close behavior in the CLI always 'writes'/modifies the database files regardless of my desire. Make sense? - Howard _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users