1
0
mirror of https://github.com/sqlite/sqlite.git synced 2025-07-29 08:01:23 +03:00

In RBU, avoid passing VFS xShmLock calls through to the underlying VFS in cases where xShmMap calls may not be. This fixes a bad interaction with ZipVFS.

FossilOrigin-Name: bd1e9e0a4c0e07901ef59fe3b7e6f7b9cc66ccfcd5192f576e1620820891de99
This commit is contained in:
dan
2021-02-10 17:31:50 +00:00
parent 82ab4f6b1a
commit 8737d46ea1
3 changed files with 16 additions and 13 deletions

View File

@ -4828,11 +4828,14 @@ static int rbuVfsShmLock(sqlite3_file *pFile, int ofst, int n, int flags){
#endif
assert( p->openFlags & (SQLITE_OPEN_MAIN_DB|SQLITE_OPEN_TEMP_DB) );
if( pRbu && (pRbu->eStage==RBU_STAGE_OAL || pRbu->eStage==RBU_STAGE_MOVE) ){
/* Magic number 1 is the WAL_CKPT_LOCK lock. Preventing SQLite from
** taking this lock also prevents any checkpoints from occurring.
** todo: really, it's not clear why this might occur, as
** wal_autocheckpoint ought to be turned off. */
if( pRbu && (
pRbu->eStage==RBU_STAGE_OAL
|| pRbu->eStage==RBU_STAGE_MOVE
|| pRbu->eStage==RBU_STAGE_DONE
)){
/* Prevent SQLite from taking a shm-lock on the target file when it
** is supplying heap memory to the upper layer in place of *-shm
** segments. */
if( ofst==WAL_LOCK_CKPT && n==1 ) rc = SQLITE_BUSY;
}else{
int bCapture = 0;