On Wed, Aug 30, 2017 at 9:20 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> On Wed, Aug 30, 2017 at 8:04 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: >>> We might need to redesign the GUC-propagation mechanism so it sends >>> the various internal representations of GUC values, not the user-visible >>> strings. > >> That would probably be better in the long run, but I'm not keen to do >> it in a back-branch under time pressure. > > Definitely a valid objection. But before assuming that this issue is > limited to SET ROLE, it'd be wise to push a bit on the other GUCs with > catalog-dependent values, to see if there are any others we need to > worry about. I"m okay with a narrow solution if SET ROLE really is > the only problem, but at this stage I'm not convinced of that.
I don't think the problem with role is that it's catalog-dependent, but that the effective value is changed by code that never calls SetConfigOption() or set_config_option() or anything other mechanism that the GUC code knows about. That coding pattern is known to be broken (see the commit message for a16d421ca4fc639929bc964b2585e8382cf16e33, for example) and my bet is the only reason why set role has gotten by with it for so long is because the code was written a long time ago and nobody wants to risk breaking anything by trying to clean it up. It's almost unfair to blame this on parallel query; if someone were to submit a patch tomorrow that changes the effective value of a GUC without going through SetConfigOption(), you'd punt it into outer space at relativistic speed. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers