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.)
[Action required within three days. This is a generic notification.]
The above-described topic is currently a PostgreSQL 10 open item. Robert,
since you committed the patch believed to have created it, you own this open
item. If some other commit is more relevant or if this does not belong as a
v10 open item, please let us know. Otherwise, please observe the policy on
open item ownership[1] and send a status update within three calendar days of
this message. Include a date for your subsequent status update. Testers may
discover new open items at any time, and I want to plan to get them all fixed
well in advance of shipping v10. Consequently, I will appreciate your efforts
toward speedy resolution. Thanks.
[1] https://www.postgresql.org/message-id/20170404140717.GA2675809%40tornado.leadboat.com