Robert Haas <robertmhaas@gmail.com> writes:
> On Wed, Aug 30, 2017 at 9:20 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> I"m okay with a narrow solution if SET ROLE really is
>> the only problem, but at this stage I'm not convinced of that.
> I don't think the problem with role is that it's catalog-dependent,
> but that the effective value is changed by code that never calls
> SetConfigOption() or set_config_option() or anything other mechanism
> that the GUC code knows about.
It's certainly possible that that's a contributing factor, but the
variant that Amit alluded to demonstrates that catalog dependency
is part of the problem:
regression=# create user testuser1;
CREATE ROLE
regression=# \c - testuser1
You are now connected to database "regression" as user "testuser1".
-- in a different session, do "drop user testuser1;", then:
regression=> show role;role
------none
(1 row)
regression=> show session authorization;session_authorization
-----------------------testuser1
(1 row)
regression=> select count(*) from pg_class;count
------- 1113
(1 row)
regression=> set force_parallel_mode TO 1;
SET
regression=> select count(*) from pg_class;
ERROR: role with OID 110981 does not exist
CONTEXT: parallel worker
regression=> set force_parallel_mode TO 0;
SET
regression=> select count(*) from pg_class;count
------- 1113
(1 row)
The problem here is exactly that we cannot transmit the leader's
state to the worker. You can't blame it on SET ROLE, because
I didn't do one.
regards, tom lane
