From: drh <drh@noemail.net>
Date: Wed, 26 May 2010 17:31:58 +0000 (+0000)
Subject: Make sure the wal-index mapping is always large enough to cover the entire
X-Git-Tag: version-3.7.2~333
X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=bab7b91e99ffb03f4113df5ab9922cc33fcc7634;p=thirdparty%2Fsqlite.git

Make sure the wal-index mapping is always large enough to cover the entire
active area of the wal-index.

FossilOrigin-Name: 42705babba0e9d2ef078845854bebbd168f23366
---

diff --git a/manifest b/manifest
index c5c5d4f7fb..e92b974915 100644
--- a/manifest
+++ b/manifest
@@ -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-----
diff --git a/manifest.uuid b/manifest.uuid
index 26655fd897..291c774fa3 100644
--- a/manifest.uuid
+++ b/manifest.uuid
@@ -1 +1 @@
-72de00731245277b2209103ec0a76e3d4f56530e
\ No newline at end of file
+42705babba0e9d2ef078845854bebbd168f23366
\ No newline at end of file
diff --git a/src/wal.c b/src/wal.c
index cd27449ac5..2bbbdcd5e7 100644
--- a/src/wal.c
+++ b/src/wal.c
@@ -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 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( 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 );