Handle an SQLITE_BUSY_TIMEOUT error if one occurs while attempting a shared lock on a read-lock slot.

FossilOrigin-Name: 5fbf3906d272df3eb981f67455eb35f649ad2774cba9fc3f077b28d9bef3f0cb

1 files changed, 2 insertions, 1 deletions

diff --git a/src/wal.c b/src/wal.c
index a15114710..2bdaa1c3f 100644
--- a/src/wal.c
+++ b/src/wal.c
@@ -3134,7 +3134,8 @@ static int walTryBeginRead(Wal *pWal, int *pChanged, int useWal, int cnt){
   rc = walLockShared(pWal, WAL_READ_LOCK(mxI));
   walDisableBlocking(pWal);
   if( rc ){
-    return rc==SQLITE_BUSY ? WAL_RETRY : rc;
+    assert( (rc&0xFF)!=SQLITE_BUSY||rc==SQLITE_BUSY||rc==SQLITE_BUSY_TIMEOUT );
+    return (rc&0xFF)==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