Fix a bug in sqlite3_snapshot_recover() that could cause subsequent read

transactions to use out-of-data cache entries.

FossilOrigin-Name: 9abeb7980a34cec11a3420e14ad98a4ec0d9c599

manifest

@@ -1,5 +1,5 @@
-C Add\sexperimental\ssqlite3_snapshot_recover()\sAPI.
-D 2016-11-18T20:49:43.736
+C Fix\sa\sbug\sin\ssqlite3_snapshot_recover()\sthat\scould\scause\ssubsequent\sread\ntransactions\sto\suse\sout-of-data\scache\sentries.
+D 2016-11-19T14:53:22.181
 F Makefile.in 6b572807415d3f0a379cebc9461416d8df4a12c8
 F Makefile.linux-gcc 7bc79876b875010e8c8f9502eb935ca92aa3c434
 F Makefile.msc bb4d970894abbbe0e88d00aac29bd52af8bc95f4
@@ -465,7 +465,7 @@ F src/vdbesort.c 91fda3909326860382b0ca8aa251e609c6a9d62c
 F src/vdbetrace.c 41963d5376f0349842b5fc4aaaaacd7d9cdc0834
 F src/vtab.c e02cacb5c7ae742631edeb9ae9f53d399f093fd8
 F src/vxworks.h d2988f4e5a61a4dfe82c6524dd3d6e4f2ce3cdb9
-F src/wal.c 5ef877f34c1becb8aaff337bb24544462117a79b
+F src/wal.c df90cfbeb84788a05947da40bc821c834a29b085
 F src/wal.h 06b2a0b599cc0f53ea97f497cf8c6b758c999f71
 F src/walker.c 91a6df7435827e41cff6bb7df50ea00934ee78b0
 F src/where.c 952f76e7a03727480b274b66ca6641b1657cd591
@@ -1103,7 +1103,7 @@ F test/skipscan3.test ec5bab3f81c7038b43450e7b3062e04a198bdbb5
 F test/skipscan5.test 67817a4b6857c47e0e33ba3e506da6f23ef68de2
 F test/skipscan6.test 5866039d03a56f5bd0b3d172a012074a1d90a15b
 F test/snapshot.test 85735bd997a4f6d710140c28fd860519a299649f
-F test/snapshot2.test 26949814860534949672dc007877062719b57c39
+F test/snapshot2.test aeacd61be9ad4aafdab183e9137eeca87623edad
 F test/snapshot_fault.test 062ff0438a074978d45e9f9a92e7ad459b74ee73
 F test/soak.test 0b5b6375c9f4110c828070b826b3b4b0bb65cd5f
 F test/softheap1.test 843cd84db9891b2d01b9ab64cef3e9020f98d087
@@ -1535,7 +1535,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 83b658dad091211ade3594d1e8d00ce525882506
-R 3db63b187961b7fe3d252e007ca73669
+P 174a6076a8d7bebe5efebf55f3fdc5d87c589cc7
+R d8309c01b710e62ecca9fb17e1bbb17f
 U dan
-Z 5c1ddc1fb889cebc1f3b9de248414272
+Z 62bf95225417162d453d1041ff22e883

manifest.uuid

@@ -1 +1 @@
-174a6076a8d7bebe5efebf55f3fdc5d87c589cc7
+9abeb7980a34cec11a3420e14ad98a4ec0d9c599

src/wal.c

@@ -2432,7 +2432,12 @@ int sqlite3WalSnapshotRecover(Wal *pWal){
       walUnlockExclusive(pWal, WAL_CKPT_LOCK, 1);
     }
 
+    /* End the read transaction opened above. Also zero the cache of the
+    ** wal-index header to force the pager-cache to be flushed when the next
+    ** read transaction is open, as it may not match the current contents of
+    ** pWal->hdr. */
     sqlite3WalEndReadTransaction(pWal);
+    memset(&pWal->hdr, 0, sizeof(WalIndexHdr));
   }
 
   return rc;

test/snapshot2.test

@@ -79,6 +79,7 @@ execsql COMMIT
 db2 close
 
 #-------------------------------------------------------------------------
+# Simple tests for sqlite3_snapshot_recover().
 #
 reset_db
 do_execsql_test 2.0 {
@@ -136,6 +137,26 @@ do_test 2.5 {
   list [catch { sqlite3_snapshot_open_blob db main $snap } msg] $msg
 } {1 SQLITE_BUSY_SNAPSHOT}
 
+#-------------------------------------------------------------------------
+# Check that calling sqlite3_snapshot_recover() does not confuse the
+# pager cache.
+reset_db
+do_execsql_test 3.0 {
+  PRAGMA journal_mode = wal;
+  CREATE TABLE t1(x, y);
+  INSERT INTO t1 VALUES('a', 'b');
+  INSERT INTO t1 VALUES('c', 'd');
+} {wal}
+do_test 3.1 {
+  sqlite3 db2 test.db
+  execsql { INSERT INTO t1 VALUES('e', 'f') } db2
+  db2 close
+  sqlite3_snapshot_recover db main
+} {}
+breakpoint
+do_execsql_test 3.2 {
+  SELECT * FROM t1;
+} {a b c d e f}
 
 finish_test