Relax the locking requirements on BTree cursors. Any number of read and

write cursors can be open at the same time now, but a write cannot occur
as long as one or more read cursors are open.

Before this change, one or more read cursors could be open on a table,
or a single write cursor, but not both.  Both policies have the same
desirable effect: they prevent writes to a table while a sequential scan
of that table is underway.  But the new policy is a little less restrictive.
Both policies prevent an UPDATE from occurring inside a SELECT (which is
what we want) but the new policy allows a SELECT to occur inside an
UPDATE. (CVS 739)

FossilOrigin-Name: 8c2a0836980341faa479cfe6c716409e6057367d

src/vdbe.c

@@ -30,7 +30,7 @@
 ** But other routines are also provided to help in building up
 ** a program instruction by instruction.
 **
-** $Id: vdbe.c,v 1.173 2002/08/28 03:01:00 drh Exp $
+** $Id: vdbe.c,v 1.174 2002/09/01 23:20:46 drh Exp $
 */
 #include "sqliteInt.h"
 #include <ctype.h>
@@ -2959,6 +2959,10 @@ case OP_Transaction: {
         }
         break;
       }
+      case SQLITE_READONLY: {
+        rc = SQLITE_OK;
+        /* Fall thru into the next case */
+      }
       case SQLITE_OK: {
         busy = 0;
         break;