database/sqlite
1
0
Fork 0
mirror of https://github.com/sqlite/sqlite.git synced 2025-08-07 02:42:48 +03:00
Code Activity

Clarify the purpose of a test for a race-condition in walIndexReadHdr().

Browse Source 
FossilOrigin-Name: c041c6a9786bc9ebb82527f7a2c96d255aec927f
This commit is contained in:
dan
2010-06-05 18:34:26 +00:00
parent 493cc590b6
commit eb8cb3a851
3 changed files with 30 additions and 9 deletions
Download Patch File Download Diff File Expand all files Collapse all files

12
manifest
View File

@@ -1,5 +1,5 @@
C Remove\sa\scondition\sfrom\ssqlite3WalRead()\sthat\sis\sunreachable\sas\sof\sthe\schanges\sto\sclear\sentries\sout\sof\sthe\swal-index\shash\stables\son\stransaction\sor\ssavepoint\srollback.
D 2010-06-05T18:12:24
C Clarify\sthe\spurpose\sof\sa\stest\sfor\sa\srace-condition\sin\swalIndexReadHdr().
D 2010-06-05T18:34:26
F Makefile.arm-wince-mingw32ce-gcc fcd5e9cd67fe88836360bb4f9ef4cb7f8e2fb5a0
F Makefile.in a5cad1f8f3e021356bfcc6c77dc16f6f1952bbc3
F Makefile.linux-gcc d53183f4aa6a9192d249731c90dbdffbd2c68654
@@ -224,7 +224,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 22a58cdfc167d29353480f1a587d844997120518
F src/wal.c a97ac7ee623fd92140bb0b37bc210b9cccb283f5
F src/wal.h 4ace25262452d17e7d3ec970c89ee17794004008
F src/walker.c 3112bb3afe1d85dc52317cb1d752055e9a781f8f
F src/where.c 75fee9e255b62f773fcadd1d1f25b6f63ac7a356
@@ -817,7 +817,7 @@ F tool/speedtest2.tcl ee2149167303ba8e95af97873c575c3e0fab58ff
F tool/speedtest8.c 2902c46588c40b55661e471d7a86e4dd71a18224
F tool/speedtest8inst1.c 293327bc76823f473684d589a8160bde1f52c14e
F tool/vdbe-compress.tcl d70ea6d8a19e3571d7ab8c9b75cba86d1173ff0f
P 3fe0cc784ac586358c08f87fba458dfbb5eec6f2
R 2aa1b1d87a9dc475383f9885b8e6d33d
P 394204735a842b04b677cca20485b1578e475d4c
R 27fd1a32d66f249d5fa488d9e53b7946
U dan
Z e4cbf876bae12325e294a44d5e590e7b
Z ac39f481b39b4a8a76aecf6dead9965f

2
manifest.uuid
View File

@@ -1 +1 @@
394204735a842b04b677cca20485b1578e475d4c
c041c6a9786bc9ebb82527f7a2c96d255aec927f

25
src/wal.c
View File

@@ -1745,6 +1745,7 @@ static int walTryBeginRead(Wal *pWal, int *pChanged, int useWal, int cnt){
** and can be safely ignored.
*/
rc = walLockShared(pWal, WAL_READ_LOCK(0));
sqlite3OsShmBarrier(pWal->pDbFd);
if( rc==SQLITE_OK ){
if( memcmp(pHdr, &pWal->hdr, sizeof(WalIndexHdr)) ){
/* It is not safe to allow the reader to continue here if frames
@@ -1817,9 +1818,29 @@ static int walTryBeginRead(Wal *pWal, int *pChanged, int useWal, int cnt){
if( rc ){
return rc==SQLITE_BUSY ? WAL_RETRY : rc;
}
/* Now that the read-lock has been obtained, check that neither the
** value in the aReadMark[] array or the contents of the wal-index
** header have changed.
**
** It is necessary to check that the wal-index header did not change
** between the time it was read and when the shared-lock was obtained
** on WAL_READ_LOCK(mxI) was obtained to account for the possibility
** that the log file may have been wrapped by a writer, or that frames
** that occur later in the log than pWal->hdr.mxFrame may have been
** copied into the database by a checkpointer. If either of these things
** happened, then reading the database with the current value of
** pWal->hdr.mxFrame risks reading a corrupted snapshot. So, retry
** instead.
**
** This does not guarantee that the copy wal-index header is up to
** date before proceeding. This would not be possible without somehow
** blocking writers. It only guarantees that a damaging checkpoint or
** log-wrap (either of which would require an exclusive lock on
** WAL_READ_LOCK(mxI)) has not occurred since the snapshot was valid.
*/
sqlite3OsShmBarrier(pWal->pDbFd);
if( pInfo->aReadMark[mxI]!=mxReadMark
|| pHdr[0].mxFrame!=pWal->hdr.mxFrame
|| (sqlite3OsShmBarrier(pWal->pDbFd), pHdr[1].mxFrame!=pWal->hdr.mxFrame)
|| memcmp(pHdr, &pWal->hdr, sizeof(WalIndexHdr))
){
walUnlockShared(pWal, WAL_READ_LOCK(mxI));
return WAL_RETRY;