On Sat, Sep 2, 2017 at 12:21 PM, Noah Misch <noah@leadboat.com> wrote:
> On Thu, Aug 31, 2017 at 03:11:10PM -0400, Robert Haas wrote:
>> On Wed, Aug 30, 2017 at 11:19 AM, Robert Haas <robertmhaas@gmail.com> wrote:
>> > 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).
>>
>> Could I get some opinions on the virtues of this approach, vs. any of
>> the other suggestions at or near
>> http://postgr.es/m/CA+TgmoaSP90E33-MU2YpGs73TtJ37m5Hv-xqHjc7TPqX9wX8ew@mail.gmail.com
>> ?
>
> It seems good to me, better than the other options in that mail. This does
> rely on "role" being on the only vulnerable GUC. Looking at callers of
> GUC_check_errmsg(), I don't expect trouble in any other GUC. (I suspect one
> can hit the "permission denied to set role" during parallel initialization
> after a concurrent ALTER ROLE removes a membership.)
>
I think that error won't happen during parallel initialization because
of 'InitializingParallelWorker' check.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com