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:

Reply via email to