Horton

Re: BUG #15324: Non-deterministic behaviour from parallelised sub-query

Amit Kapila <amit.kapila16@gmail.com>

View thread
From: Amit Kapila <amit.kapila16@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Marko Tiikkaja <marko@joh.to>, Andres Freund <andres@anarazel.de>, andy@prestigedigital.com, PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>
Date: 2018-08-14T07:36:07Z
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 →

  1. Don't allow LIMIT/OFFSET clause within sub-selects to be pushed to workers.

  2. Back-patch "Fix parallel hash join path search."

  3. Prohibit pushing subqueries containing window function calculation to

  4. Fix parallel hash join path search.

Attachments

On Tue, Aug 14, 2018 at 9:40 AM, Amit Kapila <amit.kapila16@gmail.com> wrote:
> On Mon, Aug 13, 2018 at 10:56 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> As Tom said, it is evident from the plan that the Limit clause is
> pushed in the inner-side of the parallel plan and not all the workers
> compute the same result set for the inner side.
>
>> Likely, we need to treat the presence of a LIMIT/OFFSET in a sub-select
>> as making it parallel-unsafe, for exactly the reason that that makes
>> its results non-deterministic.
>>
>
> Yeah, one idea could be that we detect this in
> max_parallel_hazard_walker during the very first pass it performs on
> query-tree.
>

I have written a patch along those lines.  This is still a WIP patch
and it is mainly to demonstrate what I have in mind.  There is one
test in select_parallel.sql failing after this patch, but I think that
is expected and we need to adjust that test.   Let me know if you see
a flaw in this approach?

-- 
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com