Horton

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

Marko Tiikkaja <marko@joh.to>

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

On Tue, Aug 14, 2018 at 7:10 AM, Amit Kapila <amit.kapila16@gmail.com>
wrote:

> Yeah, one idea could be that we detect this in
> max_parallel_hazard_walker during the very first pass it performs on
> query-tree.  Basically, in the SubLink node check, we can detect
> whether the subselect has Limit/Offset clause and if so, then we can
> treat it as parallel_unsafe.  I have tried that way and it prohibits
> the parallel plan for the reported queries.  However, I think more
> analysis and verification is required to see if it can happen in any
> other related cases.
>

This seems broken as well:

    create table qwr(a int not null, b int not null, c text not null);
    insert into qwr select i, i, (select prosrc from pg_proc where
oid=11734) from generate_series(1, 128000) i;
    set parallel_setup_cost to 0;
    analyze qwr;
    select count(*) from qwr where (a, b) in (select a, row_number() over()
from qwr);


.m