On Wed, Aug 30, 2017 at 9:20 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Wed, Aug 30, 2017 at 8:04 AM, Tom Lane <tgl@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