Hi,
On 2017-06-03 17:40:08 +0530, Amit Kapila wrote:
> The standard_planner check is sufficient to not generate parallel
> plans for such statements, but it won't prevent if such commands
> (which shouldn't be executed by parallel workers) are present in
> functions. Consider a hypothetical case as below:
>
> 1. Create a parallel safe function containing Copy commands.
> create or replace function parallel_copy(a integer) returns integer
> as $$
> begin
> Copy (select * from t1 where c1 < 2) to 'e:\\f1';
> return a;
> end;
> $$ language plpgsql Parallel Safe;
>
> 2. Now use this in some command which can be executed in parallel.
> explain analyze select * from t1 where c1 < parallel_copy(10);
>
> This can allow Copy command to be executed by parallel workers if we
> don't have sufficient safeguards.
Yes. But I'm unclear what does that have to do with the change
discussed in this thread? The pg_plan_query in copy.c setting
CURSOR_OPT_PARALLEL_OK doesn't meaningfully change the risk of this
happening in one way or the other.
> We already tried to prohibit it in
> plpgsql like in function _SPI_execute_plan(), we call
> PreventCommandIfParallelMode. However, inspite of that, we have
> safeguards in lower level calls, so that if the code flow reaches such
> commands in parallel mode, we error out. We have a similar check in
> Copy From code flow ( PreventCommandIfParallelMode("COPY FROM");) as
> well, but I think we should have it in Copy To flow as well.
Why? What is it effectively preventing? Multiple workers copying to
the same file? Any such function would have the same risk for separate
sessions.
Greetings,
Andres Freund
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
