Re: Wrong results from Parallel Hash Full Join
Melanie Plageman <melanieplageman@gmail.com>
From: Melanie Plageman <melanieplageman@gmail.com>
To: Michael Paquier <michael@paquier.xyz>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Andres Freund <andres@anarazel.de>, Thomas Munro <thomas.munro@gmail.com>, Richard Guo <guofenglinux@gmail.com>, pgsql-hackers@postgresql.org
Date: 2023-06-12T14:09:20Z
Lists: pgsql-hackers
On Sun, Jun 11, 2023 at 11:24 PM Michael Paquier <michael@paquier.xyz> wrote: > > On Wed, Jun 07, 2023 at 05:16:12PM -0400, Melanie Plageman wrote: > > On Fri, May 19, 2023 at 8:05 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: > >> 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. > > > > Yes, this was an oversight on my part. Attached is the patch that does > > just what you suggested. > > Confirmed that adding an ORDER BY adds a Sort node between a Gather > Merge and a Parallel Hash Full Join, not removing coverage. > > This has fallen through the cracks and conchuela has failed again > today, so I went ahead and applied the fix on HEAD. Thanks! Thanks!
Commits
-
Fix instability in regression test for Parallel Hash Full Join
- 3e8da50244a8 16.0 landed