Fix instability in regression test for Parallel Hash Full Join
authorMichael Paquier <michael@paquier.xyz>
Mon, 12 Jun 2023 03:19:46 +0000 (12:19 +0900)
committerMichael Paquier <michael@paquier.xyz>
Mon, 12 Jun 2023 03:19:46 +0000 (12:19 +0900)
As reported by buildfarm member conchuela, one of the regression tests
added by 558c9d7 is having some ordering issues.  This commit adds an
ORDER BY clause to make the output more stable for the problematic
query.

Fix suggested by Tom Lane.  The plan of the query updated still uses a
parallel hash full join.

Author: Melanie Plageman
Discussion: https://postgr.es/m/623596.1684541098@sss.pgh.pa.us

src/test/regress/expected/join_hash.out
src/test/regress/sql/join_hash.sql

index e892e7cccbf85d29b4fdf4ff9b5fec94f63f6ff7..4faf010f8c07d534ff975af01b95f26a08ff8abb 100644 (file)
@@ -971,7 +971,8 @@ INSERT INTO hjtest_matchbits_t2 VALUES (2);
 -- Update should create a HOT tuple. If this status bit isn't cleared, we won't
 -- correctly emit the NULL-extended unmatching tuple in full hash join.
 UPDATE hjtest_matchbits_t2 set id = 2;
-SELECT * FROM hjtest_matchbits_t1 t1 FULL JOIN hjtest_matchbits_t2 t2 ON t1.id = t2.id;
+SELECT * FROM hjtest_matchbits_t1 t1 FULL JOIN hjtest_matchbits_t2 t2 ON t1.id = t2.id
+  ORDER BY t1.id;
  id | id 
 ----+----
   1 |   
index 06bab7a4c780f6b0c367c2abb4449a9b3cdd31f4..e73f645e9ef79b02b47fc29763dfaf99a525293e 100644 (file)
@@ -523,7 +523,8 @@ INSERT INTO hjtest_matchbits_t2 VALUES (2);
 -- Update should create a HOT tuple. If this status bit isn't cleared, we won't
 -- correctly emit the NULL-extended unmatching tuple in full hash join.
 UPDATE hjtest_matchbits_t2 set id = 2;
-SELECT * FROM hjtest_matchbits_t1 t1 FULL JOIN hjtest_matchbits_t2 t2 ON t1.id = t2.id;
+SELECT * FROM hjtest_matchbits_t1 t1 FULL JOIN hjtest_matchbits_t2 t2 ON t1.id = t2.id
+  ORDER BY t1.id;
 -- Test serial full hash join.
 -- Resetting parallel_setup_cost should force a serial plan.
 -- Just to be safe, however, set enable_parallel_hash to off, as parallel full