Re: Wrong results from Parallel Hash Full Join - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Wrong results from Parallel Hash Full Join
Date
Msg-id 623596.1684541098@sss.pgh.pa.us
Whole thread Raw
In response to Re: Wrong results from Parallel Hash Full Join  (Justin Pryzby <pryzby@telsasoft.com>)
Responses Re: Wrong results from Parallel Hash Full Join
List pgsql-hackers
I noticed that BF animal conchuela has several times fallen over on the
test case added by 558c9d75f:

diff -U3 /home/pgbf/buildroot/HEAD/pgsql.build/src/test/regress/expected/join_hash.out
/home/pgbf/buildroot/HEAD/pgsql.build/src/test/regress/results/join_hash.out
--- /home/pgbf/buildroot/HEAD/pgsql.build/src/test/regress/expected/join_hash.out    2023-04-19 10:20:26.159840000
+0200
+++ /home/pgbf/buildroot/HEAD/pgsql.build/src/test/regress/results/join_hash.out    2023-04-19 10:21:47.971900000 +0200
@@ -974,8 +974,8 @@
 SELECT * FROM hjtest_matchbits_t1 t1 FULL JOIN hjtest_matchbits_t2 t2 ON t1.id = t2.id;
  id | id
 ----+----
-  1 |
     |  2
+  1 |
 (2 rows)

 -- Test serial full hash join.

Considering that this is a parallel plan, I don't think there's any
mystery about why an ORDER-BY-less query might have unstable output
order; the only mystery is why more of the buildfarm hasn't failed.
Can we just add "ORDER BY t1.id" to this query?  It looks like you
get the same PHJ plan, although now underneath Sort/Gather Merge.

            regards, tom lane

[1] https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=conchuela&dt=2023-04-19%2008%3A20%3A56
[2] https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=conchuela&dt=2023-05-03%2006%3A21%3A03
[3] https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=conchuela&dt=2023-05-19%2022%3A21%3A04



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: PG 16 draft release notes ready
Next
From: Peter Geoghegan
Date:
Subject: Avoiding another needless ERROR during nbtree page deletion