[Tom Lane <tgl@sss.pgh.pa.us>]

I came across this misbehavior:

regression=# create or replace function foo() returns text as
$$select current_setting('role')$$ language sql
parallel safe set role = postgres;
CREATE FUNCTION
regression=# select foo();
   foo    
----------
 postgres
(1 row)

regression=# set debug_parallel_query to 1;
SET
regression=# select foo();
ERROR:  cannot set parameters during a parallel operation
CONTEXT:  parallel worker

What is failing is the attempt to update the "is_superuser" GUC
as a side-effect of setting "role".  That's coming from here:

    /*
     * GUC_ACTION_SAVE changes are acceptable during a parallel operation,
     * because the current worker will also pop the change.  We're probably
     * dealing with a function having a proconfig entry.  Only the function's
     * body should observe the change, and peer workers do not share in the
     * execution of a function call started by this worker.
     *
     * Other changes might need to affect other workers, so forbid them.
     */
    if (IsInParallelMode() && changeVal && action != GUC_ACTION_SAVE)
        // throw error

Since we're using GUC_ACTION_SET to set "is_superuser", this spits up.

The simplest fix would be to hack this test to allow the action anyway
when context == PGC_INTERNAL, excusing that as "assume the caller
knows what it's doing".  That feels pretty grotty though.  Perhaps
a cleaner way would be to move this check to some higher code level,
but I'm not sure where would be a good place.

Thoughts?

			regards, tom lane