Lines Matching refs:Wal
948 ** persistent [WAL | Write Ahead Log] setting. By default, the auxiliary
951 ** closes. Setting persistent WAL mode causes those files to persist after
954 ** to read the database file, as the WAL and shared memory files must exist
957 ** That integer is 0 to disable persistent WAL mode or 1 to enable persistent
958 ** WAL mode. If the integer is -1, then it is overwritten with the current
959 ** WAL persistence setting.
6509 ** wal file in wal mode databases, or the number of pages written to the
7213 ** [journal_mode | journal_mode=WAL mode]).
7285 ** [WAL | write-ahead log mode] then this interface is a harmless no-op.
7294 ** run whenever the WAL reaches a certain size threshold.
7303 ** Run a checkpoint operation on WAL database zDb attached to database
7358 ** specified operation is attempted on all WAL databases. In this case the
7361 ** attached WAL databases, the operation is still attempted on any remaining
7368 ** If database zDb is the name of an attached database that is not in WAL
7377 int *pnLog, /* OUT: Size of WAL log in frames */
7736 ** checkpointing the database in WAL mode.
23509 ** test.db-wal => test.wal
24310 #define UNIXFILE_PERSIST_WAL 0x04 /* Persistent WAL mode */
24830 ** The m parameter will be non-zero only when creating -wal, -journal,
28256 ** When multiple threads all reference the same wal-index, each thread
28258 ** of this unixShmNode object. In other words, each wal-index is opened
28669 ** Check to see if it has been allocated (i.e. if the wal-index file is
29793 ** But if the file being opened is a WAL or regular journal file, then
29796 ** possible, WAL and journal files are created using the same permissions
29820 /* zPath is a path to a WAL or journal file. The following block derives
29825 ** "<path to db>-wal"
29936 /* The main DB, main journal, WAL file and master journal are never
30031 ** journal or WAL file, set the ownership of the journal or WAL to be
32012 ** Compiling and using WAL mode requires several APIs that are only
32016 # error "WAL mode requires support from the Windows NT kernel, compile\
32148 ** Do we need to manually define the Win32 file mapping APIs for use with WAL
32198 /* Forward references to structures used for WAL */
32255 #define WINFILE_PERSIST_WAL 0x04 /* Persistent WAL mode */
35791 sqlite3_int64 sz; /* Current size of wal-index file */
35796 ** Check to see if it has been allocated (i.e. if the wal-index file is
36550 /* The main DB, main journal, WAL file and master journal are never
40129 /************** Include wal.h in the middle of pager.c ***********************/
40130 /************** Begin file wal.h *********************************************/
40180 /* Connection to a write-ahead log (WAL) file.
40183 typedef struct Wal Wal;
40186 SQLITE_PRIVATE int sqlite3WalOpen(sqlite3_vfs*, sqlite3_file*, const char *, int, i64, Wal**);
40187 SQLITE_PRIVATE int sqlite3WalClose(Wal *pWal, int sync_flags, int, u8 *);
40189 /* Set the limiting size of a WAL file. */
40190 SQLITE_PRIVATE void sqlite3WalLimit(Wal*, i64);
40196 ** write to or checkpoint the WAL. sqlite3WalCloseSnapshot() closes the
40199 SQLITE_PRIVATE int sqlite3WalBeginReadTransaction(Wal *pWal, int *);
40200 SQLITE_PRIVATE void sqlite3WalEndReadTransaction(Wal *pWal);
40203 SQLITE_PRIVATE int sqlite3WalFindFrame(Wal *, Pgno, u32 *);
40204 SQLITE_PRIVATE int sqlite3WalReadFrame(Wal *, u32, int, u8 *);
40206 /* If the WAL is not empty, return the size of the database. */
40207 SQLITE_PRIVATE Pgno sqlite3WalDbsize(Wal *pWal);
40210 SQLITE_PRIVATE int sqlite3WalBeginWriteTransaction(Wal *pWal);
40211 SQLITE_PRIVATE int sqlite3WalEndWriteTransaction(Wal *pWal);
40214 SQLITE_PRIVATE int sqlite3WalUndo(Wal *pWal, int (*xUndo)(void *, Pgno), void *pUndoCtx);
40217 ** position in the WAL */
40218 SQLITE_PRIVATE void sqlite3WalSavepoint(Wal *pWal, u32 *aWalData);
40220 /* Move the write position of the WAL back to iFrame. Called in
40222 SQLITE_PRIVATE int sqlite3WalSavepointUndo(Wal *pWal, u32 *aWalData);
40225 SQLITE_PRIVATE int sqlite3WalFrames(Wal *pWal, int, PgHdr *, Pgno, int, int);
40229 Wal *pWal, /* Write-ahead log connection */
40236 int *pnLog, /* OUT: Number of frames in WAL */
40237 int *pnCkpt /* OUT: Number of backfilled frames in WAL */
40241 ** number of frames in the WAL at the point of the last commit since
40245 SQLITE_PRIVATE int sqlite3WalCallback(Wal *pWal);
40247 /* Tell the wal layer that an EXCLUSIVE lock has been obtained (or released)
40250 SQLITE_PRIVATE int sqlite3WalExclusiveMode(Wal *pWal, int op);
40252 /* Return true if the argument is non-NULL and the WAL module is using
40253 ** heap-memory for the wal-index. Otherwise, if the argument is NULL or the
40254 ** WAL module is using shared-memory, return false.
40256 SQLITE_PRIVATE int sqlite3WalHeapMemory(Wal *pWal);
40259 /* If the WAL file is not empty, return the number of bytes of content
40260 ** stored in each frame (i.e. the db page-size when the WAL was created).
40262 SQLITE_PRIVATE int sqlite3WalFramesize(Wal *pWal);
40268 /************** End of wal.h *************************************************/
40275 ** journal. These invariants do not apply for journal_mode=WAL,
40431 ** rollback (non-WAL) mode are met. Unless the pager is (or recently
40448 ** * If the database is a WAL database, then the WAL connection is open.
40466 ** IN WAL mode, WalBeginWriteTransaction() is called to lock the log file.
40473 ** * If the connection is open in WAL-mode, a WAL write transaction
40497 ** when it modifies the contents of the database file. WAL connections
40510 ** It is not possible for a WAL connection to enter this state.
40587 ** connection is open in WAL mode. A WAL connection is always in one
40698 u32 aWalData[WAL_SAVEPOINT_NDATA]; /* WAL savepoint context */
40873 u8 walSyncFlags; /* SYNC_NORMAL or SYNC_FULL for wal writes */
40876 u8 noLock; /* Do not lock (except in WAL mode) */
40947 Wal *pWal; /* Write-ahead log used by "journal_mode=wal" */
41160 /* It is possible that if journal_mode=wal here that neither the
41161 ** journal file nor the WAL file are open. This happens during
41163 ** to journal_mode=wal.
41252 p->journalMode==PAGER_JOURNALMODE_WAL ? "wal" : "?error?"
42248 /* Drop the WAL write-lock, if any. Also, if the connection was in
43200 ** written into the log file when a WAL transaction is rolled back.
43235 ** database. This is not generally possible with a WAL database, as
43247 ** This function is called to rollback a transaction on a WAL database.
43304 /* If a WAL transaction is being committed, there is no point in writing
43305 ** any pages with page numbers greater than nTruncate into the WAL file.
43345 ** Begin a read transaction on the WAL.
43388 /* Query the WAL sub-system for the database size. The WalDbsize()
43389 ** function returns zero if the WAL is not open (i.e. Pager.pWal==0), or
43391 ** available from the WAL sub-system if the log file is empty or
43398 /* If the database size was not available from the WAL sub-system,
43430 ** Check if the *-wal file that corresponds to the database opened by pPager
43431 ** exists if the database is not empy, or verify that the *-wal file does
43434 ** If the database is not empty and the *-wal file exists, open the pager
43435 ** in WAL mode. If the database is empty or if no *-wal file exists and
43443 ** a WAL on a none-empty database, this ensures there is no race condition
43453 int isWal; /* True if WAL file exists */
43687 ** The above is for a rollback-journal mode. For WAL mode, OFF continues
43688 ** to mean that no syncs ever occur. NORMAL means that the WAL is synced
43690 ** at the conclusion of the checkpoint if the entire content of the WAL
43692 ** an ordinary commit in NORMAL mode with WAL. FULL means that the WAL
43974 ** to WAL mode yet.
44900 memcpy(&pPager->zWal[nPathname], "-wal\000", 4+1);
45421 /* If there is a WAL file in the file-system, open this database in WAL
45522 u32 iFrame = 0; /* Frame to read from WAL file */
45865 ** WAL mode sets Pager.eState to PAGER_WRITER_LOCKED or CACHEMOD
45870 ** WAL mode.
46284 ** rollback. If the connection is in WAL mode, this call is a no-op.
46289 ** successful, or the connection is in WAL mode, SQLITE_OK is returned.
46366 /* Must have at least one page for the WAL commit flag.
46565 ** In WAL mode, all cache-entries containing data modified within the
46568 ** WAL files. The WAL transaction is then closed.
46905 ** This function is called by the wal module when writing page content
47159 ** to WAL mode.
47180 ** mode except WAL, unless the pager is in locking_mode=exclusive mode,
47336 ** Call sqlite3WalOpen() to open the WAL handle. If the pager is in
47338 ** lock on the database file and use heap-memory to store the wal-index
47347 /* If the pager is already in exclusive-mode, the WAL module will use
47348 ** heap-memory for the wal-index instead of the VFS shared-memory
47349 ** implementation. Take the exclusive lock now, before opening the WAL
47376 ** file (not a temp file or an in-memory database), and the WAL file
47383 ** the WAL file is already open, set *pbOpen to 1 and return SQLITE_OK
47418 ** to switching from WAL to rollback mode.
47467 ** the pager is in WAL mode and the WAL file currently contains one or more
47469 ** WAL frames. Otherwise, if this is not a WAL database or the WAL file
47481 /************** Begin file wal.c *********************************************/
47494 ** This file contains the implementation of a write-ahead log (WAL) used in
47495 ** "journal_mode=WAL" mode.
47497 ** WRITE-AHEAD LOG (WAL) FILE FORMAT
47499 ** A WAL file consists of a header followed by zero or more "frames".
47502 ** frames into the WAL. Transactions commit when a frame is written that
47503 ** contains a commit marker. A single WAL can and usually does record
47504 ** multiple transactions. Periodically, the content of the WAL is
47508 ** A single WAL file can be used multiple times. In other words, the
47509 ** WAL can fill up with frames and then be checkpointed and then new
47510 ** frames can overwrite the old ones. A WAL always grows from beginning
47512 ** used to determine which frames within the WAL are valid and which
47515 ** The WAL header is 32 bytes in size and consists of the following eight
47527 ** Immediately following the wal-header are zero or more frames. Each
47544 ** salt values in the wal-header
47548 ** WAL header and the first 8 bytes and the content of all frames
47552 ** magic number in the first 4 bytes of the WAL is 0x377f0683 and it
47570 ** On a checkpoint, the WAL is first VFS.xSync-ed, then valid content of the
47571 ** WAL is transferred into the database, then the database is VFS.xSync-ed.
47577 ** value is randomized. This prevents old and new frames in the WAL from
47584 ** first checks the WAL to see if it contains page P. If so, then the
47586 ** or is a commit frame itself becomes the value read. If the WAL
47592 ** valid frame in the WAL. The reader uses this recorded "mxFrame" value
47594 ** to the WAL, but as long as the reader uses its original mxFrame value
47601 ** because frames for page P can appear anywhere within the WAL, the
47602 ** reader has to scan the entire WAL looking for page P frames. If the
47603 ** WAL is large (multiple megabytes is typical) that scan can be slow,
47605 ** data structure called the wal-index is maintained to expedite the
47608 ** WAL-INDEX FORMAT
47610 ** Conceptually, the wal-index is shared memory, though VFS implementations
47611 ** might choose to implement the wal-index using a mmapped file. Because
47612 ** the wal-index is shared memory, SQLite does not support journal_mode=WAL
47616 ** The wal-index is transient. After a crash, the wal-index can (and should
47617 ** be) reconstructed from the original WAL file. In fact, the VFS is required
47618 ** to either truncate or zero the header of the wal-index when the last
47619 ** connection to it closes. Because the wal-index is transient, it can
47621 ** Hence, unlike the database and WAL file formats which store all values
47622 ** as big endian, the wal-index can store multi-byte values in the native
47625 ** The purpose of the wal-index is to answer this question quickly: Given
47627 ** last frame in the wal before frame M for page P in the WAL, or return
47628 ** NULL if there are no frames for page P in the WAL prior to M.
47630 ** The wal-index consists of a header region, followed by an one or
47633 ** The wal-index header contains the total number of frames within the WAL
47639 ** HASHTABLE_NPAGE are selected so that together the wal-index header and
47641 ** wal-index.
47644 ** database page number associated with each wal frame, and a hash-table
47649 ** first frame in the WAL file. The first entry in the second index block
47650 ** in the WAL file corresponds to the (HASHTABLE_NPAGE_ONE+1)th frame in
47653 ** The last index block in a wal-index usually contains less than the full
47655 ** depending on the contents of the WAL file. This does not change the
47702 ** to cover a typical 10 megabyte WAL file, assuming 1K pages. 8 or 10
47704 ** WAL or to establish that the frame does not exist in the WAL. This
47705 ** is much faster than scanning the entire 10MB WAL.
47709 ** at a later time (after additional transactions were added to the WAL
47710 ** and to the wal-index) might be using a different value K1, where K1>K0.
47738 ** The maximum (and only) versions of the wal and wal-index formats
47741 ** If a client begins recovering a WAL file and finds that (a) the checksum
47742 ** values in the wal-header are correct and (b) the version field is not
47745 ** Similarly, if a client successfully reads a wal-index header (i.e. the
47772 ** The following object holds a copy of the wal-index header content.
47774 ** The actual header in the wal-index consists of two copies of this
47782 u32 iVersion; /* Wal-index version */
47786 u8 bigEndCksum; /* True if checksums in WAL are big-endian */
47788 u32 mxFrame; /* Index of last valid frame in the WAL */
47791 u32 aSalt[2]; /* Two salt values copied from WAL header */
47796 ** A copy of the following object occurs in the wal-index immediately
47800 ** nBackfill is the number of frames in the WAL that have been written
47801 ** back into the database. (We call the act of moving content from WAL to
47806 ** mxFrame back to zero when the WAL is reset.
47814 ** WAL_READ_LOCK(0) always ignore the entire WAL and read all content
47822 ** The checkpointer may only transfer frames from WAL to database where
47829 ** in the WAL has been backfilled into the database) then new readers
47832 ** the WAL.
47834 ** Writers normally append new frames to the end of the WAL. However,
47835 ** if nBackfill equals mxFrame (meaning that all WAL content has been
47836 ** written back into the database) and if no readers are using the WAL
47838 ** the writer will first "reset" the WAL back to the beginning and start
47845 u32 nBackfill; /* Number of WAL frames backfilled into DB */
47860 /* Size of header before each frame in wal */
47867 /* WAL magic value. Either this value, or the same value with the least
47869 ** big-endian format in the first 4 bytes of a WAL file.
47871 ** If the LSB is set, then the checksums for each frame within the WAL
47891 struct Wal {
47894 WAL file */
47896 i64 mxWalSize; /* Truncate WAL to this size upon reset */
47898 int szFirstBlock; /* Size of first block written to WAL file */
47899 volatile u32 **apWiData; /* Pointer to wal-index content in memory */
47907 u8 truncateOnCommit; /* True to truncate WAL file on commit */
47908 u8 syncHeader; /* Fsync the WAL header if true */
47910 WalIndexHdr hdr; /* Wal-index header for current transaction */
47911 const char *zWalName; /* Name of WAL file */
47912 u32 nCkpt; /* Checkpoint sequence counter in the wal-header */
47919 ** Candidate values for Wal.exclusiveMode.
47926 ** Possible values for WAL.readOnly
47929 #define WAL_RDONLY 1 /* The WAL file is readonly */
47933 ** Each page of the wal-index mapping contains a hash-table made up of
47940 ** all frames in the WAL in database page order. Where two or more frames
47942 ** frame most recently written to the WAL (in other words, the frame with
47962 } aSegment[1]; /* One for every 32KB page in the wal-index */
47966 ** Define the parameters of the hash tables in the wal-index file. There
47968 ** wal-index.
47970 ** Changing any of these constants will alter the wal-index format and
47979 ** wal-index is smaller than usual. This is so that there is a complete
47980 ** hash-table on each aligned 32KB page of the wal-index.
47984 /* The wal-index is divided into pages of WALINDEX_PGSZ bytes each. */
47990 ** Obtain a pointer to the iPage'th page of the wal-index. The wal-index
47991 ** is broken into pages of WALINDEX_PGSZ bytes. Wal-index pages are
47994 ** If this call is successful, *ppPage is set to point to the wal-index
47998 static int walIndexPage(Wal *pWal, int iPage, volatile u32 **ppPage){
48038 ** Return a pointer to the WalCkptInfo structure in the wal-index.
48040 static volatile WalCkptInfo *walCkptInfo(Wal *pWal){
48046 ** Return a pointer to the WalIndexHdr structure in the wal-index.
48048 static volatile WalIndexHdr *walIndexHdr(Wal *pWal){
48112 static void walShmBarrier(Wal *pWal){
48119 ** Write the header information in pWal->hdr into the wal-index.
48123 static void walIndexWriteHdr(Wal *pWal){
48144 ** 8: Salt-1 (copied from the wal-header)
48145 ** 12: Salt-2 (copied from the wal-header)
48150 Wal *pWal, /* The write-ahead log */
48177 Wal *pWal, /* The write-ahead log */
48189 ** match the salt values in the wal-header.
48202 /* A frame is only valid if a checksum of the WAL header,
48249 ** Set or release locks on the WAL. Locks are either shared or exclusive.
48255 static int walLockShared(Wal *pWal, int lockIdx){
48260 WALTRACE(("WAL%p: acquire SHARED-%s %s\n", pWal,
48265 static void walUnlockShared(Wal *pWal, int lockIdx){
48269 WALTRACE(("WAL%p: release SHARED-%s\n", pWal, walLockName(lockIdx)));
48271 static int walLockExclusive(Wal *pWal, int lockIdx, int n){
48276 WALTRACE(("WAL%p: acquire EXCLUSIVE-%s cnt=%d %s\n", pWal,
48281 static void walUnlockExclusive(Wal *pWal, int lockIdx, int n){
48285 WALTRACE(("WAL%p: release EXCLUSIVE-%s cnt=%d\n", pWal,
48305 ** page iHash of the wal-index. The wal-index is broken into 32KB pages
48309 ** in the wal-index file. Set *piZero to one less than the frame
48318 Wal *pWal, /* WAL handle */
48350 ** Return the number of the wal-index page that contains the hash-table
48351 ** and page-number array that contain entries corresponding to WAL frame
48352 ** iFrame. The walWal-index pages
48367 ** Return the page number associated with frame iFrame in this WAL.
48369 static u32 walFramePgno(Wal *pWal, u32 iFrame){
48378 ** Remove entries from the hash table that point to WAL slots greater
48389 static void walCleanupHash(Wal *pWal){
48448 ** Set an entry in the wal-index that will map database page number
48449 ** pPage into WAL frame iFrame.
48451 static int walIndexAppend(Wal *pWal, u32 iFrame, u32 iPage){
48459 /* Assuming the wal-index file was successfully mapped, populate the
48480 ** writing one or more dirty pages to the WAL to free up memory).
48531 ** Recover the wal-index by reading the write-ahead log file.
48534 ** wal-index to prevent other threads/processes from doing anything
48535 ** with the WAL or wal-index while recovery is running. The
48540 static int walIndexRecover(Wal *pWal){
48563 WALTRACE(("WAL%p: recovery begin...\n", pWal));
48573 u8 aBuf[WAL_HDRSIZE]; /* Buffer to load WAL header into */
48580 u32 magic; /* Magic value read from WAL header */
48581 u32 version; /* Magic value read from WAL header */
48584 /* Read in the WAL header. */
48591 ** SQLITE_MAX_PAGE_SIZE, conclude that the WAL file contains no valid
48593 ** WAL file.
48609 /* Verify that the WAL header checksum is correct */
48619 /* Verify that the version number on the WAL format is one that
48691 "recovered %d frames from WAL file %s",
48698 WALTRACE(("WAL%p: recovery %s\n", pWal, rc ? "failed" : "ok"));
48704 ** Close an open wal-index.
48706 static void walIndexClose(Wal *pWal, int isDelete){
48719 ** Open a connection to the WAL file zWalName. The database file must
48721 ** to must remain valid for the lifetime of the returned Wal* handle.
48725 ** client from unlinking the WAL or wal-index file. If another process
48730 ** *ppWal is set to point to a new WAL handle. If an error occurs,
48734 sqlite3_vfs *pVfs, /* vfs module to open wal and wal-index */
48736 const char *zWalName, /* Name of the WAL file */
48738 i64 mxWalSize, /* Truncate WAL to this size on reset */
48739 Wal **ppWal /* OUT: Allocated Wal handle */
48742 Wal *pRet; /* Object to allocate and return */
48760 /* Allocate an instance of struct Wal to return. */
48762 pRet = (Wal*)sqlite3MallocZero(sizeof(Wal) + pVfs->szOsFile);
48795 WALTRACE(("WAL%d: opened\n", pRet));
48801 ** Change the size to which the WAL file is trucated on each reset.
48803 SQLITE_PRIVATE void sqlite3WalLimit(Wal *pWal, i64 iLimit){
48808 ** Find the smallest page number out of all pages held in the WAL that
48811 ** that page was last written into the WAL. Write into *piPage the page
48814 WAL with a page
48820 u32 *piFrame /* OUT: Wal frame index of next page */
48871 const u32 *aContent, /* Pages in wal - keys for the sort */
48928 const u32 *aContent, /* Pages in wal */
48992 ** pages in the WAL in ascending order. The caller must hold the checkpoint
49002 static int walIteratorInit(Wal *pWal, WalIterator **pp){
49079 ** Attempt to obtain the exclusive WAL lock defined by parameters lockIdx and
49085 Wal *pWal, /* WAL connection */
49099 ** The cache of the wal-index header must be valid to call this function.
49102 static int walPagesize(Wal *pWal){
49107 ** Copy as much content as we can from the WAL back into the database file
49110 ** The amount of information copies from WAL to database might be limited
49115 ** SQLite is in WAL-mode in synchronous=NORMAL. That means that if
49119 ** Fsync is called on the WAL before writing content out of the WAL and
49121 ** in the WAL and can be recovered following a power-loss or hard reset.
49124 ** WAL content is copied into the database file. This second fsync makes
49125 ** it safe to delete the WAL since the new content will persist in the
49128 ** This routine uses and updates the nBackfill field of the wal-index header.
49130 ** (A WAL reset or recovery will revert nBackfill to zero, but not increase
49138 Wal *pWal, /* Wal connection */
49147 WalIterator *pIter = 0; /* Wal iterator context */
49149 u32 iFrame = 0; /* Wal frame containing data for iDbpage */
49171 /* Compute in mxSafeFrame the index of the last frame of the WAL that is
49174 ** cannot be backfilled from the WAL.
49201 /* Sync the WAL to disk */
49218 /* Iterate through the contents of the WAL, copying data to the db file. */
49224 /* testcase( IS_BIG_INT(iOffset) ); // requires a 4GiB WAL file */
49258 /* If this is an SQLITE_CHECKPOINT_RESTART operation, and the entire wal
49260 ** readers have finished using the wal file. This ensures that the next
49261 ** process to write to the database restarts the wal file.
49282 ** If the WAL file is currently larger than nMax bytes in size, truncate
49285 static void walLimitSize(Wal *pWal, i64 nMax){
49295 sqlite3_log(rx, "cannot limit WAL size: %s", pWal->zWalName);
49303 Wal *pWal, /* Wal to close */
49310 int isDelete = 0; /* True to unlink wal and wal-index files */
49316 ** the wal and wal-index files.
49334 /* Try to delete the WAL file if the checkpoint completed and
49335 ** fsyned (rc==SQLITE_OK) and if we are not in persistent-wal
49339 /* Try to truncate the WAL file to zero bytes if the checkpoint
49341 ** WAL mode (bPersist) and if the PRAGMA journal_size_limit is a
49344 ** leave a corrupt WAL file on disk. */
49357 WALTRACE(("WAL%p: closed\n", pWal));
49365 ** Try to read the wal-index header. Return 0 on success and 1 if
49368 ** The wal-index is in shared memory. Another thread or process might
49381 static int walIndexTryHdr(Wal *pWal, int *pChanged){
49386 /* The first page of the wal-index must be mapped at this point. */
49394 ** There are two copies of the header at the beginning of the wal-index.
49428 ** Read the wal-index header from the wal-index and into pWal->hdr.
49429 ** If the wal-header appears to be corrupt, try to reconstruct the
49430 ** wal-index from the WAL before returning.
49432 ** Set *pChanged to 1 if the wal-index header value in pWal->hdr is
49436 ** If the wal-index header is successfully read, return SQLITE_OK.
49439 static int walIndexReadHdr(Wal *pWal, int *pChanged){
49442 volatile u32 *page0; /* Chunk of wal-index containing header */
49444 /* Ensure that page 0 of the wal-index (the page that contains the
49445 ** wal-index header) is mapped. Return early if an error occurs here.
49454 /* If the first page of the wal-index has been mapped, try to read the
49455 ** wal-index header immediately, without holding any lock. This usually
49456 ** works, but may fail if the wal-index header is corrupt or currently
49476 /* If the wal-index header is still malformed even while holding
49490 ** sure the wal-index was not constructed with some future format that
49515 ** The useWal parameter is true to force the use of the WAL and disable
49516 ** the case where the WAL is bypassed because it has been completely
49518 ** to make a copy of the wal-index header into pWal->hdr. If the
49519 ** wal-index header has changed, *pChanged is set to 1 (as an indication
49521 ** flushed.) When useWal==1, the wal-index header is assumed to already
49532 ** bad luck when there is lots of contention for the wal-index, but that
49538 ** that means the Wal does not hold any read lock. The reader must not
49539 ** access any database page that is modified by a WAL frame up to and
49541 ** use WAL frames up to and including pWal->hdr.mxFrame if pWal->readLock>0
49542 ** Or if pWal->readLock==0, then the reader will ignore the WAL
49544 ** If the useWal parameter is 1 then the WAL will never be ignored and
49556 static int walTryBeginRead(Wal *pWal, int *pChanged, int useWal, int cnt){
49557 volatile WalCkptInfo *pInfo; /* Checkpoint information in wal-index */
49626 /* The WAL has been completely backfilled (or it is empty).
49657 ** the WAL to get at content from recent commits. The job now is
49698 ** value in the aReadMark[] array or the contents of the wal-index
49701 ** It is necessary to check that the wal-index header did not change
49711 ** This does not guarantee that the copy of the wal-index header is up to
49735 ** it takes a snapshot of the state of the WAL and wal-index for the current
49737 ** Other threads might append new content to the WAL and wal-index but
49745 SQLITE_PRIVATE int sqlite3WalBeginReadTransaction(Wal *pWal, int *pChanged){
49763 SQLITE_PRIVATE void sqlite3WalEndReadTransaction(Wal *pWal){
49772 ** Search the wal file for page pgno. If found, set *piRead to the frame that
49773 ** contains the page. Otherwise, if pgno is not in the wal file, set *piRead
49780 Wal *pWal, /* WAL handle */
49784 u32 iRead = 0; /* If !=0, WAL frame to return data from */
49785 u32 iLast = pWal->hdr.mxFrame; /* Last page in WAL for this reader */
49791 /* If the "last page" field of the wal-index header snapshot is 0, then
49792 ** no data will be read from the wal under any circumstances. Return early
49794 ** then the WAL is ignored by the reader so return early, as if the
49795 ** WAL were empty.
49807 ** that adds entries to the wal-index (and possibly to this hash
49854 ** of the wal-index file content. Make sure the results agree with the
49874 ** Read the contents of frame iRead from the wal file into buffer pOut
49879 Wal *pWal, /* WAL handle */
49891 /* testcase( IS_BIG_INT(iOffset) ); // requires a 4GiB WAL */
49898 SQLITE_PRIVATE Pgno sqlite3WalDbsize(Wal *pWal){
49907 ** This function starts a write transaction on the WAL.
49919 SQLITE_PRIVATE int sqlite3WalBeginWriteTransaction(Wal *pWal){
49956 SQLITE_PRIVATE int sqlite3WalEndWriteTransaction(Wal *pWal){
49970 ** to the WAL since the start of the transaction. If the callback returns
49977 SQLITE_PRIVATE int sqlite3WalUndo(Wal *pWal, int (*xUndo)(void *, Pgno), void *pUndoCtx){
49983 /* Restore the clients cache of the wal-index header to the state it
50015 ** "rollback" the write position of the WAL handle back to the current
50018 SQLITE_PRIVATE void sqlite3WalSavepoint(Wal *pWal, u32 *aWalData){
50027 ** Move the write position of the WAL back to the point identified by
50032 SQLITE_PRIVATE int sqlite3WalSavepointUndo(Wal *pWal, u32 *aWalData){
50070 static int walRestartLog(Wal *pWal){
50083 ** readers are currently using the WAL), then the transactions
50085 ** wal-index header to reflect this.
50088 ** at this point. But updating the actual wal-index header is also
50125 ** Information about the current state of the WAL file and where
50130 Wal *pWal; /* The complete WAL information */
50131 sqlite3_file *pFd; /* The WAL file to which we write */
50138 ** Write iAmt bytes of content into the WAL file beginning at iOffset.
50146 WalWriter *p, /* WAL to write to */
50168 ** Write out a single frame of the WAL
50197 Wal *pWal, /* Wal handle to write to */
50210 i64 iOffset; /* Next byte to write in WAL file */
50222 WALTRACE(("WAL%p: frame write begin. %d frames. mxFrame=%d. %s\n",
50234 /* If this is the first frame written into the log, write the WAL
50235 ** header to the start of the WAL file. See comments at the top of
50236 ** this source file for a description of the WAL header format.
50240 u8 aWalHdr[WAL_HDRSIZE]; /* Buffer to assemble wal-header in */
50241 u32 aCksum[2]; /* Checksum for wal-header */
50260 WALTRACE(("WAL%p: wal-header write %s\n", pWal, rc ? "failed" : "ok"));
50267 ** an out-of-order write following a WAL restart could result in
50279 /* Setup information needed to write frames into the WAL */
50301 ** the transaction and/or sync the WAL file.
50310 ** boundary is crossed. Only the part of the WAL prior to the last
50329 /* If this frame set completes the first transaction in the WAL and
50330 ** if PRAGMA journal_size_limit is set, then truncate the WAL to the
50342 /* Append data to the wal-index. It is not necessary to lock the
50343 ** wal-index to do this as the SQLITE_SHM_WRITE lock held on the wal-index
50368 /* If this is a commit, update the wal-index header too. */
50375 WALTRACE(("WAL%p: frame write %s\n", pWal, rc ? "failed" : "ok"));
50384 ** we can from WAL into the database.
50390 Wal *pWal, /* Wal connection */
50397 int *pnLog, /* OUT: Number of frames in WAL */
50398 int *pnCkpt /* OUT: Number of backfilled frames in WAL */
50401 int isChanged = 0; /* True if a new wal-index header is loaded */
50408 WALTRACE(("WAL%p: checkpoint begins\n", pWal));
50437 /* Read the wal-index header. */
50461 /* If a new wal-index header was loaded before the checkpoint was
50463 ** out of date. So zero the cached wal-index header to ensure that
50474 WALTRACE(("WAL%p: checkpoint %s\n", pWal, rc ? "failed" : "ok"));
50479 ** number of frames in the WAL at the point of the last commit since
50483 SQLITE_PRIVATE int sqlite3WalCallback(Wal *pWal){
50493 ** This function is called to change the WAL subsystem into or out
50498 ** on the pWal->readLock byte. If the WAL is already in locking_mode=NORMAL
50507 ** WAL is already in exclusive-locking mode - meaning that this
50516 SQLITE_PRIVATE int sqlite3WalExclusiveMode(Wal *pWal, int op){
50554 ** Return true if the argument is non-NULL and the WAL module is using
50555 ** heap-memory for the wal-index. Otherwise, if the argument is NULL or the
50556 ** WAL module is using shared-memory, return false.
50558 SQLITE_PRIVATE int sqlite3WalHeapMemory(Wal *pWal){
50564 ** If the argument is not NULL, it points to a Wal object that holds a
50568 SQLITE_PRIVATE int sqlite3WalFramesize(Wal *pWal){
50576 /************** End of wal.c *************************************************/
53982 ** in WAL mode. If the log is not already open, open it now. Then
55634 ** 5) the database is not a WAL database,
60031 ** WAL connection, even if the version fields are currently set to 2.
60447 /* Do not allow backup if the destination database is in WAL mode
73731 ** WAL mode. Parameter P2 is one of SQLITE_CHECKPOINT_PASSIVE, FULL
73734 ** WAL after the checkpoint into mem[P3+1] and the number of pages
73735 ** in the WAL that have been checkpointed after the checkpoint
73771 ** If changing into or out of WAL mode the procedure is more complicated.
73805 /* Do not allow a transition to journal_mode=WAL for a database
73821 "cannot change %s wal mode from within a transaction",
73828 /* If leaving WAL mode, close the log file. If successful, the call
73838 /* Cannot transition directly from MEMORY to WAL. Use mode OFF
98876 , "wal"
99202 ** (delete|persist|off|truncate|memory|wal|off)
109164 ** to ensure that we do not try to change the page-size on a WAL database.
109171 /* Do not attempt to change the page size for a WAL database */
123827 int nFrame /* Size of WAL */
123892 int *pnLog, /* OUT: Size of WAL log in frames */
123942 ** not currently open in WAL mode.
