On Mon, Nov 21, 2016 at 11:43 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> I wrote:
>> Like Ashutosh, I can't reproduce the crash, so it's hard to speculate much
>> further.
>
> Ah-hah: now I can. The recipe lacks these important steps:
>
> set parallel_setup_cost TO 0;
> set parallel_tuple_cost TO 0;
>
> That changes the plan to
>
> Limit (cost=0.00..0.06 rows=1 width=64)
> -> Nested Loop (cost=0.00..57.25 rows=1000 width=64)
> -> Function Scan on pg_show_all_settings a (cost=0.00..10.00 rows=1000 width=64)
> -> Limit (cost=0.00..0.03 rows=1 width=32)
> -> Gather (cost=0.00..3.54 rows=130 width=32)
> Workers Planned: 2
> -> Parallel Seq Scan on pg_opclass (cost=0.00..3.54 rows=54 width=32)
>
> so what we've got is a case where a parameter computed by the FunctionScan
> (in the master) would need to be passed into the parallel workers at
> runtime. Do we have code for that at all? If so where is it?
No, that's not supposed to happen. That's why we have this:
/* * We can't pass Params to workers at the moment either, so they are also * parallel-restricted. */
elseif (IsA(node, Param)) { if (max_parallel_hazard_test(PROPARALLEL_RESTRICTED, context)) return
true; }
Maybe it's checking the quals but not recursing into the tlist?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company