Re: BUG #15324: Non-deterministic behaviour from parallelised sub-query
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Amit Kapila <amit.kapila16@gmail.com>
Cc: Stephen Frost <sfrost@snowman.net>, Marko Tiikkaja <marko@joh.to>,
Andres Freund <andres@anarazel.de>,
Andrew Fletcher <andy@prestigedigital.com>,
PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>
Date: 2018-09-03T13:49:17Z
Lists: pgsql-bugs
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Don't allow LIMIT/OFFSET clause within sub-selects to be pushed to workers.
- 568b4e1fdeb3 9.6.11 landed
- 1ceb103e7d1e 10.6 landed
- 830d7565902f 11.0 landed
- 75f9c4ca5a80 12.0 landed
-
Back-patch "Fix parallel hash join path search."
- 271b678436ce 9.6.11 landed
-
Prohibit pushing subqueries containing window function calculation to
- f658235a448a 9.6.11 landed
- bf61873ae3b6 10.6 landed
- 14e9b2a752ef 12.0 landed
- 2ce253cf57b1 11.0 landed
-
Fix parallel hash join path search.
- 655393a022bd 10.0 cited
Amit Kapila <amit.kapila16@gmail.com> writes: > You haven't mentioned anything about backpatching, but I don't see any > problem with backpatching this fix. Yeah, we definitely need to back-patch, and that's another reason not to touch the catalog contents. > I will commit the attached patches in a day or so unless somebody sees > any problem. Looking more closely at the patch: * The general design in max_parallel_hazard_walker appears to be that after the initial check_functions_in_node test, the rest of it should be an if ... else if ... else if ... else if ... chain of mutually-exclusive IsA tests. Whoever stuck in the NextValueExpr test (possibly me?) did so with a tin ear, and you've duplicated that mistake here. Please make it "else if", and fix the NextValueExpr test to be "else if" while at it. (Or else get rid of all the "else"s, but that would be a shade less efficient unless the compiler is very very smart.) * The plan tree for the added test case is hard to read because it's unclear which tenk1 scan is which. I'd suggest adding aliases to clarify that, eg +explain (costs off, verbose) + select count(*) from tenk1 a where (unique1, two) in + (select unique1, row_number() over() from tenk1 b); HEAD patch is OK otherwise. I didn't look at the back-branch patches. regards, tom lane