Re: Parallel worker error

On Wed, Aug 30, 2017 at 8:04 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> We might need to redesign the GUC-propagation mechanism so it sends
> the various internal representations of GUC values, not the user-visible
> strings.

That would probably be better in the long run, but I'm not keen to do
it in a back-branch under time pressure. I think one approach is to
stick another test against InitializingParallelWorker into check_role,
making it treat that case like no-role-specified. But I'm a little
worried about whether that would ever lead to a case where the role
should get set and doesn't, leading to a security bug.

Another approach is to attack this problem right at the root, which
IMHO is that changing "session_authorization" is implicitly setting
"role", but for the reasons mentioned in the comment in show_role(),
it doesn't set it explicitly. Well, that results in a situation where
the actual value assigned to the GUC doesn't match the value that
needs to be passed to the worker, so it breaks. I'm not sure what
would be a practical approach to that problem, but it's a thought.

A third approach is to do something like what you're proposing but
just limited to "role". In particular, the obvious thing to do would
be exclude it from SerializeGUCState and somehow propagate it as part
of FixedParallelState, which already has authenticated_user_id and
current_user_id.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company