Update a couple of test cases to account for the fact that ROLLBACK does not always abort all running SELECT statements.

FossilOrigin-Name: eba171e980fa4491dfee9d7e4df50c87a0ebbf87

test/ioerr2.test

@@ -112,6 +112,12 @@ foreach bPersist [list 0 1] {
   }
 }
 
+# When this test was written, an IO error within the UPDATE statement caused
+# a rollback, which tripped all read-cursors, causing the outer SELECT to
+# fail with "abort due to ROLLBACK". Now, the loop continues until the UPDATE
+# is run successfully. At this point the next IO error occurs within the 
+# SELECT - throwing the "disk I/O error" that the test case now expects.
+#
 do_test ioerr2-5 {
   execsql {
     CREATE TABLE t2 AS SELECT * FROM t1;
@@ -130,7 +136,7 @@ do_test ioerr2-5 {
     }
   } msg]
   list $rc $msg
-} {1 {abort due to ROLLBACK}}
+} {1 {disk I/O error}} ;# used to be "{1 {abort due to ROLLBACK}}"
 
 if {$::tcl_platform(platform) == "unix"} {
   # Cause the call to xAccess used by [pragma temp_store_directory] to

test/shared_err.test

@@ -446,9 +446,15 @@ do_malloc_test shared_err-8 -tclprep {
   } {1}
   db2 close
 }
+
+# When this test case was written, OOM errors in write statements would 
+# cause transaction rollback, which would trip cursors in other statements,
+# aborting them. This no longer happens.
+#
 do_test shared_malloc-8.X {
   # Test that one or more queries were aborted due to the malloc() failure.
-  expr $::aborted>=1
+  # expr $::aborted>=1
+  expr $::aborted==0
 } {1}
 
 # This test is designed to catch a specific bug that was present during