On Wed, Aug 30, 2017 at 8:04 AM, Tom Lane <t...@sss.pgh.pa.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 -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers