Robert Haas <robertmh...@gmail.com> writes:
> On Wed, Aug 30, 2017 at 9:20 AM, Tom Lane <t...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
