Many hyperlinks are disabled.
Use anonymous login
to enable hyperlinks.
Overview
| Comment: | Make sure the wal-index mapping is always large enough to cover the entire active area of the wal-index. |
|---|---|
| Downloads: | Tarball | ZIP archive | SQL archive |
| Timelines: | family | ancestors | descendants | both | trunk |
| Files: | files | file ages | folders |
| SHA1: |
42705babba0e9d2ef078845854bebbd1 |
| User & Date: | drh 2010-05-26 17:31:59 |
Context
|
2010-05-28
| ||
| 11:16 | Add a test to walcksum.test to stress the checksum calculation. (check-in: 778d0c17 user: dan tags: trunk) | |
|
2010-05-26
| ||
| 17:31 | Make sure the wal-index mapping is always large enough to cover the entire active area of the wal-index. (check-in: 42705bab user: drh tags: trunk) | |
| 15:06 | Change the semantics of xShmGet() such that it will never increase the size of shared memory. xShmSize() must be used to grow the size of shared memory. A shared memory segment size cannot be shrunk (except by dropping it). (check-in: 72de0073 user: drh tags: trunk) | |
Changes
Changes to src/wal.c.
1384
1385
1386
1387
1388
1389
1390
1391
1392
1393
1394
1395
1396
1397
1398
1399
1400
1401
1402
1403
1404
1405
1406
1407
1408
1409
1410
1411
1412
1413
1414
1415
1416
1417
1418
1419
1420
1421
1422
1423
....
1656
1657
1658
1659
1660
1661
1662
1663
1664
1665
1666
1667
1668
1669
|
** ** A dirty read of the wal-index header occurs if another thread or ** process happens to be writing to the wal-index header at roughly ** the same time as this thread is reading it. In this case it is ** possible that an inconsistent header is read (which is detected ** using the header checksum mechanism). */ if( walIndexTryHdr(pWal, pChanged)==0 ){ return SQLITE_OK; } /* 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); } } return rc; } /* ................................................................................ if( pWal->lockState==SQLITE_SHM_WRITE ){ int unused; Pgno iMax = pWal->hdr.mxFrame; Pgno iFrame; assert( pWal->pWiData==0 ); rc = walIndexReadHdr(pWal, &unused); if( rc==SQLITE_OK ){ for(iFrame=pWal->hdr.mxFrame+1; rc==SQLITE_OK && iFrame<=iMax; iFrame++){ assert( pWal->lockState==SQLITE_SHM_WRITE ); rc = xUndo(pUndoCtx, pWal->pWiData[walIndexEntry(iFrame)]); } walCleanupHash(pWal); } |
|
<
|
<
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
>
>
>
>
>
>
>
>
>
>
>
>
|
1384
1385
1386
1387
1388
1389
1390
1391
1392
1393
1394
1395
1396
1397
1398
1399
1400
1401
1402
1403
1404
1405
1406
1407
1408
1409
1410
1411
1412
1413
1414
1415
1416
1417
1418
1419
1420
1421
1422
1423
1424
1425
1426
1427
1428
1429
1430
....
1663
1664
1665
1666
1667
1668
1669
1670
1671
1672
1673
1674
1675
1676
1677
1678
1679
|
** ** A dirty read of the wal-index header occurs if another thread or ** process happens to be writing to the wal-index header at roughly ** the same time as this thread is reading it. In this case it is ** possible that an inconsistent header is read (which is detected ** using the header checksum mechanism). */ 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); } } } /* 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); } } return rc; } /* ................................................................................ if( pWal->lockState==SQLITE_SHM_WRITE ){ int unused; Pgno iMax = pWal->hdr.mxFrame; Pgno iFrame; 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 ); rc = xUndo(pUndoCtx, pWal->pWiData[walIndexEntry(iFrame)]); } walCleanupHash(pWal); } |