Further comment improvements in wal.c. No code changes.

FossilOrigin-Name: 346388007de585083dc67ad865b91db7c7d7b78c10a06f8bb7c48767c326c47e
This commit is contained in:
drh 2017-11-11 13:30:44 +00:00
parent 85bc6df2f1
commit 870655bb9e
3 changed files with 27 additions and 22 deletions

View File

@ -1,5 +1,5 @@
C Improved\scomments\sand\svariable\snames\sin\sthe\sread-only\sWAL\slogic.
D 2017-11-10T20:00:50.239
C Further\scomment\simprovements\sin\swal.c.\s\sNo\scode\schanges.
D 2017-11-11T13:30:44.595
F Makefile.in 5bae3f2f3d42f2ad52b141562d74872c97ac0fca6c54953c91bb150a0e6427a8
F Makefile.linux-gcc 7bc79876b875010e8c8f9502eb935ca92aa3c434
F Makefile.msc 3a5cb477ec3ce5274663b693164e349db63348667cd45bad78cc13d580b691e2
@ -543,7 +543,7 @@ F src/vdbesort.c 731a09e5cb9e96b70c394c1b7cf3860fbe84acca7682e178615eb941a3a0ef2
F src/vdbetrace.c 48e11ebe040c6b41d146abed2602e3d00d621d7ebe4eb29b0a0f1617fd3c2f6c
F src/vtab.c 0e4885495172e1bdf54b12cce23b395ac74ef5729031f15e1bc1e3e6b360ed1a
F src/vxworks.h d2988f4e5a61a4dfe82c6524dd3d6e4f2ce3cdb9
F src/wal.c 47f8a4493e077b312399b62fd36fd4e8b70535dcd8d9a5caf18b8be019fcf420
F src/wal.c 0e19d4fbb52085697509f9407176e732d440f372f49ca08510a65d1aa976bd07
F src/wal.h 8de5d2d3de0956d6f6cb48c83a4012d5f227b8fe940f3a349a4b7e85ebcb492a
F src/walker.c d591e8a9ccf60abb010966b354fcea4aa08eba4d83675c2b281a8764c76cc22f
F src/where.c b7a075f5fb3d912a891dcc3257f538372bb4a1622dd8ca7d752ad95ce8949ba4
@ -1669,7 +1669,7 @@ F vsixtest/vsixtest.tcl 6a9a6ab600c25a91a7acc6293828957a386a8a93
F vsixtest/vsixtest.vcxproj.data 2ed517e100c66dc455b492e1a33350c1b20fbcdc
F vsixtest/vsixtest.vcxproj.filters 37e51ffedcdb064aad6ff33b6148725226cd608e
F vsixtest/vsixtest_TemporaryKey.pfx e5b1b036facdb453873e7084e1cae9102ccc67a0
P 5a384be6979b783d1f3af2ac6307e7e731c415d052f9405f04c0216f59414633
R 4efdec1d3561b29c7744e3cfcf4d5f7b
P d3c25740eec9a2a41c29e6e488fcf6587c1fb821147a442c29439b25a92154a5
R cc050d490699d35569ec56a8515bac08
U drh
Z df395ed2f6beb277e98c44e2de48326a
Z 1e870a391397f9beedb8e100937bac44

View File

@ -1 +1 @@
d3c25740eec9a2a41c29e6e488fcf6587c1fb821147a442c29439b25a92154a5
346388007de585083dc67ad865b91db7c7d7b78c10a06f8bb7c48767c326c47e

View File

@ -2230,16 +2230,23 @@ static int walBeginShmUnreliable(Wal *pWal, int *pChanged){
** the xShmMap() routine of the VFS and looking to see if the return
** is SQLITE_READONLY instead of SQLITE_READONLY_CANTINIT.
**
** Once sqlite3OsShmMap() has been called for a file and has returned
** any SQLITE_READONLY value, it must SQLITE_READONLY or
** SQLITE_READONLY_CANTINIT or some error for all subsequent invocations,
** until sqlite3OsShmUnmap() has been called. This is a requirement
** on the VFS implementation.
**
** If the shared-memory is now "reliable" return WAL_RETRY, which will
** cause the heap-memory WAL-index to be discarded and the actual
** shared memory to be used in its place.
*/
**
** This step is important because, even though this connection is holding
** the WAL_READ_LOCK(0) which prevents a checkpoint, a writer might
** have already checkpointed the WAL file and, while the current
** is active, wrap the WAL and start overwriting frames that this
** process wants to use.
**
** Once sqlite3OsShmMap() has been called for an sqlite3_file and has
** returned any SQLITE_READONLY value, it must return only SQLITE_READONLY
** or SQLITE_READONLY_CANTINIT or some error for all subsequent invocations,
** even if some external agent does a "chmod" to make the shared-memory
** writable by us, until sqlite3OsShmUnmap() has been called.
** This is a requirement on the VFS implementation.
*/
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 ){
@ -2247,19 +2254,14 @@ static int walBeginShmUnreliable(Wal *pWal, int *pChanged){
goto begin_unreliable_shm_out;
}
/* Reach this point only if the real shared-memory is still unreliable.
/* We reach this point only if the real shared-memory is still unreliable.
** Assume the in-memory WAL-index substitute is correct and load it
** into pWal->hdr.
*/
memcpy(&pWal->hdr, (void*)walIndexHdr(pWal), sizeof(WalIndexHdr));
/* 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 this transaction, as the other client may overwrite wal
** frames that this client is still using.
/* Make sure some writer hasn't come in and changed the WAL file out
** from under us, then disconnected, while we were not looking.
*/
rc = sqlite3OsFileSize(pWal->pWalFd, &szWal);
if( rc!=SQLITE_OK ){
@ -2283,6 +2285,9 @@ static int walBeginShmUnreliable(Wal *pWal, int *pChanged){
goto begin_unreliable_shm_out;
}
if( memcmp(&pWal->hdr.aSalt, &aBuf[16], 8) ){
/* Some writer has wrapped the WAL file while we were not looking.
** Return WAL_RETRY which will cause the in-memory WAL-index to be
** rebuilt. */
rc = WAL_RETRY;
goto begin_unreliable_shm_out;
}