Fix flaky 'combocid' test.

It would sometimes fail like this:

--- /tmp/build/e18b2f02/gpdb_src/src/test/regress/expected/combocid.out	2020-08-25 03:14:48.314831054 +0000
+++ /tmp/build/e18b2f02/gpdb_src/src/test/regress/results/combocid.out	2020-08-25 03:14:48.326832158 +0000
@@ -66,7 +66,7 @@
 FETCH ALL FROM c;
  ctid  | cmin | foobar | distkey
 -------+------+--------+---------
- (0,1) |    0 |      1 |
+ (0,1) |    1 |      1 |
  (0,2) |    1 |      2 |
  (0,5) |    0 |    333 |
 (3 rows)

I was able to reproduce that locally, by inserting a random delay in the
SeqNext() function.

src/test/regress/expected/combocid.out

@@ -60,14 +60,20 @@ SELECT ctid,cmin,* FROM combocidtest;
 -- Test combo cids with portals
 BEGIN;
 INSERT INTO combocidtest VALUES (333);
-DECLARE c CURSOR FOR SELECT ctid,cmin,* FROM combocidtest;
+-- In GPDB, the cursor starts executing in the segments as soon as the
+-- DECLARE is dispatched. Usually, the cursor will fetch the first row
+-- from the table before the DELETE runs, so that it will see cmin==0
+-- on the first row. But sometimes, the DELETE will update the row first,
+-- so that the cursor will see cmin==1. Both are OK, but because it's
+-- non-deterministic, don't display the cmin value.
+DECLARE c CURSOR FOR SELECT ctid,* FROM combocidtest;
 DELETE FROM combocidtest;
 FETCH ALL FROM c;
- ctid  | cmin | foobar | distkey 
--------+------+--------+---------
- (0,1) |    0 |      1 |        
- (0,2) |    1 |      2 |        
- (0,5) |    0 |    333 |        
+ ctid  | foobar | distkey 
+-------+--------+---------
+ (0,1) |      1 |        
+ (0,2) |      2 |        
+ (0,5) |    333 |        
 (3 rows)
 
 ROLLBACK;

src/test/regress/expected/combocid_optimizer.out

@@ -60,14 +60,20 @@ SELECT ctid,cmin,* FROM combocidtest;
 -- Test combo cids with portals
 BEGIN;
 INSERT INTO combocidtest VALUES (333);
-DECLARE c CURSOR FOR SELECT ctid,cmin,* FROM combocidtest;
+-- In GPDB, the cursor starts executing in the segments as soon as the
+-- DECLARE is dispatched. Usually, the cursor will fetch the first row
+-- from the table before the DELETE runs, so that it will see cmin==0
+-- on the first row. But sometimes, the DELETE will update the row first,
+-- so that the cursor will see cmin==1. Both are OK, but because it's
+-- non-deterministic, don't display the cmin value.
+DECLARE c CURSOR FOR SELECT ctid,* FROM combocidtest;
 DELETE FROM combocidtest;
 FETCH ALL FROM c;
- ctid  | cmin | foobar | distkey 
--------+------+--------+---------
- (0,1) |    0 |      1 |        
- (0,2) |    1 |      2 |        
- (0,5) |    0 |    333 |        
+ ctid  | foobar | distkey 
+-------+--------+---------
+ (0,1) |      1 |        
+ (0,2) |      2 |        
+ (0,5) |    333 |        
 (3 rows)
 
 ROLLBACK;

src/test/regress/sql/combocid.sql

@@ -51,7 +51,13 @@ BEGIN;
 
 INSERT INTO combocidtest VALUES (333);
 
-DECLARE c CURSOR FOR SELECT ctid,cmin,* FROM combocidtest;
+-- In GPDB, the cursor starts executing in the segments as soon as the
+-- DECLARE is dispatched. Usually, the cursor will fetch the first row
+-- from the table before the DELETE runs, so that it will see cmin==0
+-- on the first row. But sometimes, the DELETE will update the row first,
+-- so that the cursor will see cmin==1. Both are OK, but because it's
+-- non-deterministic, don't display the cmin value.
+DECLARE c CURSOR FOR SELECT ctid,* FROM combocidtest;
 
 DELETE FROM combocidtest;