Re: BUG #15324: Non-deterministic behaviour from parallelised sub-query
Amit Kapila <amit.kapila16@gmail.com>
From: Amit Kapila <amit.kapila16@gmail.com>
To: Marko Tiikkaja <marko@joh.to>
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-14T11:50: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
On Tue, Aug 14, 2018 at 4:42 PM, Marko Tiikkaja <marko@joh.to> wrote: > Hi Amit, > >> > >> > 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); >> > >> >> I am getting below error in above steps: >> >> postgres=# insert into qwr select i, i, (select prosrc from >> pg_proc where oid=11734) from generate_series(1, 128000) i; >> ERROR: null value in column "c" violates not-null constraint >> DETAIL: Failing row contains (1, 1, null). > > > Sorry, try this instead: > > insert into qwr select i, i, (select prosrc from pg_proc where > oid='ts_debug(regconfig,text)'::regprocedure) from generate_series(1, > 128000) i; > This looks related, but I think this is a different issue. The real reason for this case is that row_number is marked as parallel_safe which seems to be wrong. I think it should be marked as parallel_unsafe. This needs some more analysis w.r.t which other Window functions has a similar problem. -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com