Hello,
While investing an issue in Postgres-XL 10, I came across this rather surprisingly behaviour in PG master. See this test case:
create role testuser1;
set role to testuser1;
show role; -- shows testuser1
-- reset back to default role
reset session authorization ;
show role; -- shows none
set force_parallel_mode TO 1;
select count(*) from pg_class ; -- ok
-- now drop the role and try parallel query again
drop role testuser1 ;
select count(*) from pg_class ; -- fails
The last statement in this test fails with an error:
ERROR: role "testuser1" does not exist
Looks like the leader process when serialises the GUC state, saves the "role" value, which is still set to testuser1 (and which is now dropped). Later, when the parallel worker process tries to restore the GUC state, it fails on catalog lookup.
Comments in show_role() mentions a kludge because apparently SET SESSION AUTHORIZATION cannot call set_config_option and change the current value of "role". So that probably explains why show_role() displays the correct information, but parallel worker fails to handle the case.
It's quite possible that I don't understand the differences in "role" and "session authorization", but it still looks like a bug to me. May be SerializeGUCState() should check if SetRoleIsActive is true and only then save the role information?
Thanks,
Pavan