From: Tom Lane <tgl@sss.pgh.pa.us>
To: pgsql-hackers@lists.postgresql.org
cc: Robert Haas <robertmhaas@gmail.com>
Subject: is_superuser versus set_config_option's parallelism check
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <2833456.1723229039.1@sss.pgh.pa.us>
Date: Fri, 09 Aug 2024 14:43:59 -0400
Message-ID: <2833457.1723229039@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/2833457.1723229039%40sss.pgh.pa.us>
Precedence: bulk

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