Disable parallel query in psql error-with-FETCH_COUNT test.

The buildfarm members using debug_parallel_query = regress are mostly
unhappy with this test.  I guess what is happening is that rows
generated by a parallel worker are buffered, and might or might not
get to the leader before the expected error occurs.  We did not see
any variability in the old version of this test because each FETCH
would succeed or fail atomically, leading to a predictable number of
rows emitted before failure.  I don't find this to be a bug, just
unspecified behavior, so let's disable parallel query for this one
test case to make the results stable.

Author: tglsfdc

src/test/regress/expected/psql.out

@@ -4788,6 +4788,8 @@ error code: 00000
 \echo 'number of rows:' :ROW_COUNT
 number of rows: 19
 -- chunked results with an error after the first chunk
+-- (we must disable parallel query here, else the behavior is timing-dependent)
+set debug_parallel_query = off;
 select 1/(15-unique2) from tenk1 order by unique2 limit 19;
  ?column? 
 ----------
@@ -4812,6 +4814,7 @@ number of rows: 0
 last error message: division by zero
 \echo 'last error code:' :LAST_ERROR_SQLSTATE
 last error code: 22012
+reset debug_parallel_query;
 \unset FETCH_COUNT
 create schema testpart;
 create role regress_partitioning_role;

src/test/regress/sql/psql.sql

@@ -1169,12 +1169,15 @@ select unique2 from tenk1 order by unique2 limit 19;
 \echo 'number of rows:' :ROW_COUNT
 
 -- chunked results with an error after the first chunk
+-- (we must disable parallel query here, else the behavior is timing-dependent)
+set debug_parallel_query = off;
 select 1/(15-unique2) from tenk1 order by unique2 limit 19;
 \echo 'error:' :ERROR
 \echo 'error code:' :SQLSTATE
 \echo 'number of rows:' :ROW_COUNT
 \echo 'last error message:' :LAST_ERROR_MESSAGE
 \echo 'last error code:' :LAST_ERROR_SQLSTATE
+reset debug_parallel_query;
 
 \unset FETCH_COUNT