Re: assessing parallel-safety

On Fri, Jul 3, 2015 at 5:30 PM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>
>
> Attached, find the rebased patch which can be used to review/test latest
> version of parallel_seqscan patch which I am going to post in the parallel
> seq. scan thread soonish.
>

I went ahead and completed this patch with respect to adding new clause
in CREATE/ALTER FUNCTION which can allow users to define the
parallel property for User defined functions.

The new clause is defined as

Create Function ... PARALLEL {SAFE | RESTRICTED | UNSAFE}
Alter Function ... PARALLEL {SAFE | RESTRICTED | UNSAFE}

I have added PARALLEL as non-reserved keyword and store other
parameters as options which can be verified during CreateFunction.

Apart from this, added pg_dump support and updated the docs.

I have changed the parallel safety for some of the newly added
functions for pg_replication_origin* which will be defined as:

pg_replication_origin_create - unsafe, because it can start a transaction

pg_replication_origin_drop - unsafe, because it can start a transaction

pg_replication_origin_session_setup - unsafe, because it changes shared
memory state(ReplicationState) that is not shared among workers.

pg_replication_origin_session_reset - unsafe, because it changes shared
memory state(ReplicationState) that is not shared among workers.

pg_replication_origin_advance - unsafe, because it changes shared
memory state(ReplicationState) that is not shared among workers.

pg_replication_origin_progress - unsafe, because it can call XlogFlush
which can change shared memory state.

pg_replication_origin_session_progress - unsafe, because it can call
XlogFlush which can change shared memory state.

pg_replication_origin_xact_setup - Restricted,
because replorigin_sesssion_origin_lsn is not shared

pg_replication_origin_xact_reset - Restricted,
because replorigin_sesssion_origin_lsn is not shared

pg_replication_origin_session_is_setup - Restricted,
because replorigin_sesssion_origin is not shared

pg_show_replication_origin_status - Restricted, because
ReplicationState is not shared.

pg_replication_origin_oid - Safe

One issue which I think we should fix in this patch as pointed earlier
is, in some cases, Function containing Select stmt won't be able to
use parallel plan even though it is marked as parallel safe.

create or replace function parallel_func_select() returns integer
as $$
declare
ret_val int;
begin
Select c1 into ret_val from t1 where c1 = 1;
return ret_val;
end;
$$ language plpgsql Parallel Safe;

Above function won't be able to use parallel plan for Select statement
because of below code:

static int
exec_stmt_execsql(PLpgSQL_execstate *estate,
PLpgSQL_stmt_execsql
*stmt)
{
..
if (expr->plan == NULL)
{
..
exec_prepare_plan(estate, expr, 0);
}
..
}

As the cursorOptions passed in this function are always 0, planner
will treat it as unsafe function. Shouldn't we need to check parallelOk
to pass cursoroption in above function as is done in exec_run_select()
in patch?

With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com