Make sure the wal-index mapping is always large enough to cover the entire
active area of the wal-index. FossilOrigin-Name: 42705babba0e9d2ef078845854bebbd168f23366
This commit is contained in:
@@ -1,8 +1,8 @@
|
||||
-----BEGIN PGP SIGNED MESSAGE-----
|
||||
Hash: SHA1
|
||||
|
||||
C Change\sthe\ssemantics\sof\sxShmGet()\ssuch\sthat\sit\swill\snever\sincrease\sthe\ssize\nof\sshared\smemory.\s\sxShmSize()\smust\sbe\sused\sto\sgrow\sthe\ssize\sof\sshared\smemory.\nA\sshared\smemory\ssegment\ssize\scannot\sbe\sshrunk\s(except\sby\sdropping\sit).
|
||||
D 2010-05-26T15:06:38
|
||||
C Make\ssure\sthe\swal-index\smapping\sis\salways\slarge\senough\sto\scover\sthe\sentire\nactive\sarea\sof\sthe\swal-index.
|
||||
D 2010-05-26T17:31:59
|
||||
F Makefile.arm-wince-mingw32ce-gcc fcd5e9cd67fe88836360bb4f9ef4cb7f8e2fb5a0
|
||||
F Makefile.in a5cad1f8f3e021356bfcc6c77dc16f6f1952bbc3
|
||||
F Makefile.linux-gcc d53183f4aa6a9192d249731c90dbdffbd2c68654
|
||||
@@ -227,7 +227,7 @@ F src/vdbeblob.c 5327132a42a91e8b7acfb60b9d2c3b1c5c863e0e
|
||||
F src/vdbemem.c 2a82f455f6ca6f78b59fb312f96054c04ae0ead1
|
||||
F src/vdbetrace.c 864cef96919323482ebd9986f2132435115e9cc2
|
||||
F src/vtab.c a0f8a40274e4261696ef57aa806de2776ab72cda
|
||||
F src/wal.c 603f6ad6fa9a1ff400042a2aafe26ade7a2460a9
|
||||
F src/wal.c ce631adb92c0c53d87bb86913dc6714cca825e3a
|
||||
F src/wal.h 111c6f3efd83fe2fc707b29e26431e8eff4c6f28
|
||||
F src/walker.c 3112bb3afe1d85dc52317cb1d752055e9a781f8f
|
||||
F src/where.c 75fee9e255b62f773fcadd1d1f25b6f63ac7a356
|
||||
@@ -818,14 +818,14 @@ F tool/speedtest2.tcl ee2149167303ba8e95af97873c575c3e0fab58ff
|
||||
F tool/speedtest8.c 2902c46588c40b55661e471d7a86e4dd71a18224
|
||||
F tool/speedtest8inst1.c 293327bc76823f473684d589a8160bde1f52c14e
|
||||
F tool/vdbe-compress.tcl d70ea6d8a19e3571d7ab8c9b75cba86d1173ff0f
|
||||
P 687632a6b3a0aeb006c1eda5c27d5489f08c230e
|
||||
R 10265da0d50a2ddb803b6a733956f1ed
|
||||
P 72de00731245277b2209103ec0a76e3d4f56530e
|
||||
R 3803eb711e1482685c888c1d5aad25b9
|
||||
U drh
|
||||
Z 8953a9a318d02ec6ed8374658e58a902
|
||||
Z fbf41cb9ad1e3a86d51249de0c4212ff
|
||||
-----BEGIN PGP SIGNATURE-----
|
||||
Version: GnuPG v1.4.6 (GNU/Linux)
|
||||
|
||||
iD8DBQFL/TkBoxKgR168RlERAviGAJ4+8lzL8Zi3Jko72hinaOLrZV5mAgCePzCx
|
||||
pZpI8grIC+ipxJIOxg4scYk=
|
||||
=Hslv
|
||||
iD8DBQFL/VsSoxKgR168RlERAiiyAKCNIB2cx0oWfiSWhB7rYPl7wJQPNwCffewd
|
||||
BG/+93y24TpcUQJKKPuyhOs=
|
||||
=WCDR
|
||||
-----END PGP SIGNATURE-----
|
||||
|
||||
+1
-1
@@ -1 +1 @@
|
||||
72de00731245277b2209103ec0a76e3d4f56530e
|
||||
42705babba0e9d2ef078845854bebbd168f23366
|
||||
@@ -1388,32 +1388,39 @@ static int walIndexReadHdr(Wal *pWal, int *pChanged){
|
||||
** possible that an inconsistent header is read (which is detected
|
||||
** using the header checksum mechanism).
|
||||
*/
|
||||
if( walIndexTryHdr(pWal, pChanged)==0 ){
|
||||
return SQLITE_OK;
|
||||
if( walIndexTryHdr(pWal, pChanged)!=0 ){
|
||||
|
||||
/* If the first attempt to read the header failed, lock the wal-index
|
||||
** file with an exclusive lock and try again. If the header checksum
|
||||
** verification fails again, we can be sure that it is not simply a
|
||||
** dirty read, but that the wal-index really does need to be
|
||||
** reconstructed by running log recovery.
|
||||
**
|
||||
** In the paragraph above, an "exclusive lock" may be any of WRITE,
|
||||
** PENDING, CHECKPOINT or RECOVER. If any of these are already held,
|
||||
** no locking operations are required. If the caller currently holds
|
||||
** a READ lock, then upgrade to a RECOVER lock before re-reading the
|
||||
** wal-index header and revert to a READ lock before returning.
|
||||
*/
|
||||
lockState = pWal->lockState;
|
||||
if( lockState>SQLITE_SHM_READ
|
||||
|| SQLITE_OK==(rc = walSetLock(pWal, SQLITE_SHM_RECOVER))
|
||||
){
|
||||
if( walIndexTryHdr(pWal, pChanged) ){
|
||||
*pChanged = 1;
|
||||
rc = walIndexRecover(pWal);
|
||||
}
|
||||
if( lockState==SQLITE_SHM_READ ){
|
||||
walSetLock(pWal, SQLITE_SHM_READ);
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
/* If the first attempt to read the header failed, lock the wal-index
|
||||
** file with an exclusive lock and try again. If the header checksum
|
||||
** verification fails again, we can be sure that it is not simply a
|
||||
** dirty read, but that the wal-index really does need to be
|
||||
** reconstructed by running log recovery.
|
||||
**
|
||||
** In the paragraph above, an "exclusive lock" may be any of WRITE,
|
||||
** PENDING, CHECKPOINT or RECOVER. If any of these are already held,
|
||||
** no locking operations are required. If the caller currently holds
|
||||
** a READ lock, then upgrade to a RECOVER lock before re-reading the
|
||||
** wal-index header and revert to a READ lock before returning.
|
||||
*/
|
||||
lockState = pWal->lockState;
|
||||
if( lockState>SQLITE_SHM_READ
|
||||
|| SQLITE_OK==(rc = walSetLock(pWal, SQLITE_SHM_RECOVER))
|
||||
){
|
||||
if( walIndexTryHdr(pWal, pChanged) ){
|
||||
*pChanged = 1;
|
||||
rc = walIndexRecover(pWal);
|
||||
}
|
||||
if( lockState==SQLITE_SHM_READ ){
|
||||
walSetLock(pWal, SQLITE_SHM_READ);
|
||||
/* Make sure the mapping is large enough to cover the entire wal-index */
|
||||
if( rc==SQLITE_OK ){
|
||||
int szWanted = walMappingSize(pWal->hdr.mxFrame);
|
||||
if( pWal->szWIndex<szWanted ){
|
||||
rc = walIndexMap(pWal, szWanted);
|
||||
}
|
||||
}
|
||||
|
||||
@@ -1660,6 +1667,9 @@ int sqlite3WalUndo(Wal *pWal, int (*xUndo)(void *, Pgno), void *pUndoCtx){
|
||||
|
||||
assert( pWal->pWiData==0 );
|
||||
rc = walIndexReadHdr(pWal, &unused);
|
||||
if( rc==SQLITE_OK ){
|
||||
rc = walIndexMap(pWal, walMappingSize(iMax));
|
||||
}
|
||||
if( rc==SQLITE_OK ){
|
||||
for(iFrame=pWal->hdr.mxFrame+1; rc==SQLITE_OK && iFrame<=iMax; iFrame++){
|
||||
assert( pWal->lockState==SQLITE_SHM_WRITE );
|
||||
|
||||
Reference in New Issue
Block a user