On Wed, Aug 30, 2017 at 9:58 AM, Tom Lane <tgl@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