Re: Parallel worker error

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Wed, Aug 30, 2017 at 9:20 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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