On Wed, Aug 30, 2017 at 9:58 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > 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.
Hmm, that's a good reason for holding it blameless. In this case, I'll blame the fact that we allow a role to be dropped while there are users connected using that role. That's about as sensible as allowing a table to be dropped while there are users reading from it, or a database to be dropped while there are users connected to it, both of which we in fact prohibit. IOW, I'd say the problem is that we've allowed the system state to become inconsistent and now we're sad because stuff doesn't work. But since that's an established design fl^H^Hprinciple, maybe that means we should go with the approach of teaching SerializeGUCState() to ignore role altogether and instead have ParallelWorkerMain call SetCurrentRoleId using information passed via the FixedParallelState (not sure of the precise details here). -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers