On Sat, Sep 2, 2017 at 12:21 PM, Noah Misch <n...@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 <robertmh...@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-xqhjc7tpqx9wx...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
