Many hyperlinks are disabled.
Use anonymous login
to enable hyperlinks.
Overview
| Comment: | Extra comments on the sqlite3OsShmMap() call in walBeginUnlocked(). No changes to code. |
|---|---|
| Downloads: | Tarball | ZIP archive | SQL archive |
| Timelines: | family | ancestors | descendants | both | readonly-wal-recovery |
| Files: | files | file ages | folders |
| SHA3-256: | 033ee92bf4d5dc57f5cb8fd02d1154ae06f2d3261d214e7191a82c70c8ffebf7 |
| User & Date: | drh 2017-11-08 19:26:27 |
Context
|
2017-11-09
| ||
| 16:30 | Initial work on porting the changes on this branch to Win32. check-in: 3738bfd0 user: mistachkin tags: readonly-wal-recovery | |
|
2017-11-08
| ||
| 19:26 | Extra comments on the sqlite3OsShmMap() call in walBeginUnlocked(). No changes to code. check-in: 033ee92b user: drh tags: readonly-wal-recovery | |
| 17:51 | Turns out that SQLITE_READONLY_CANTLOCK is an historical name that must be preserved. So make a new SQLITE_READLOCK_CANTINIT name instead. check-in: 04974a8b user: drh tags: readonly-wal-recovery | |
Changes
Changes to src/wal.c.
2206 2207 2208 2209 2210 2211 2212 2213 2214 2215 2216 2217 2218 2219 2220 2221 2222 2223 2224 2225 2226 2227 2228 2229 2230 |
goto begin_unlocked_out;
}
pWal->readLock = 0;
/* Try to map the *-shm file again. If it succeeds this time, then
** a non-readonly_shm connection has already connected to the database.
** In this case, start over with opening the transaction.
**
** The WAL_READ_LOCK(0) lock held by this client prevents a checkpoint
** from taking place. But it does not prevent the wal from being wrapped
** if a checkpoint has already taken place. This means that if another
** client is connected at this point, it may have already checkpointed
** the entire wal. In that case it would not be safe to continue with
** the unlocked transaction, as the other client may overwrite wal
** frames that this client is still using. */
rc = sqlite3OsShmMap(pWal->pDbFd, 0, WALINDEX_PGSZ, 0, &pDummy);
if( rc!=SQLITE_READONLY_CANTINIT ){
assert( rc!=SQLITE_OK );
rc = (rc==SQLITE_READONLY ? WAL_RETRY : rc);
goto begin_unlocked_out;
}
memcpy(&pWal->hdr, (void*)walIndexHdr(pWal), sizeof(WalIndexHdr));
rc = sqlite3OsFileSize(pWal->pWalFd, &szWal);
if( rc!=SQLITE_OK ){
|
> > > > > > > > > < |
2206 2207 2208 2209 2210 2211 2212 2213 2214 2215 2216 2217 2218 2219 2220 2221 2222 2223 2224 2225 2226 2227 2228 2229 2230 2231 2232 2233 2234 2235 2236 2237 2238 |
goto begin_unlocked_out;
}
pWal->readLock = 0;
/* Try to map the *-shm file again. If it succeeds this time, then
** a non-readonly_shm connection has already connected to the database.
** In this case, start over with opening the transaction.
**
** The *-shm file was opened read-only, so sqlite3OsShmMap() can never
** return SQLITE_OK here, as that would imply that it had established
** a read/write mapping. A return of SQLITE_READONLY means success - that
** a mapping has been established to a shared-memory segment that is actively
** maintained by a writer. SQLITE_READONLY_CANTINIT means that all
** all connections to the -shm file are read-only and hence the content
** of the -shm file might be out-of-date.
**
** The WAL_READ_LOCK(0) lock held by this client prevents a checkpoint
** from taking place. But it does not prevent the wal from being wrapped
** if a checkpoint has already taken place. This means that if another
** client is connected at this point, it may have already checkpointed
** the entire wal. In that case it would not be safe to continue with
** the unlocked transaction, as the other client may overwrite wal
** frames that this client is still using. */
rc = sqlite3OsShmMap(pWal->pDbFd, 0, WALINDEX_PGSZ, 0, &pDummy);
assert( rc!=SQLITE_OK ); /* SQLITE_OK not possible for read-only connection */
if( rc!=SQLITE_READONLY_CANTINIT ){
rc = (rc==SQLITE_READONLY ? WAL_RETRY : rc);
goto begin_unlocked_out;
}
memcpy(&pWal->hdr, (void*)walIndexHdr(pWal), sizeof(WalIndexHdr));
rc = sqlite3OsFileSize(pWal->pWalFd, &szWal);
if( rc!=SQLITE_OK ){
|