On Mon, Nov 21, 2016 at 11:43 AM, Tom Lane <t...@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.
*/
else if (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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
