Re: is_superuser versus set_config_option's parallelism check - Mailing list pgsql-hackers

Nathan Bossart <nathandbossart@gmail.com> writes:
> On Fri, Aug 09, 2024 at 04:04:15PM -0400, Tom Lane wrote:
>> Yeah, I had been thinking along the same lines.  Here's a draft
>> patch.  (Still needs some attention to nearby comments, and I can't
>> avoid the impression that the miscinit.c code in this area could
>> use refactoring.)

> Hm.  That's a bit more code than I expected.

Yeah.  I can see a couple of points of attraction in this, but
they're not strong:

* Fewer cycles involved in setting session_authorization or role.
But nobody has really complained that those are slow.

* Gets us out from any other gotchas that may exist or be added
in the SetConfigOption code path, not just this one point.
This is mostly hypothetical, and a regression test case or two
would likely catch any new problems anyway.

> Another option might be to introduce a new GUC flag or source for anything
> we want to bypass the check (perhaps with the stipulation that it must also
> be marked PGC_INTERNAL).

A new GUC flag seems like a promising approach, and better than
giving a blanket exemption to PGC_INTERNAL.  At least for
is_superuser, there's no visible value in restricting which
SetConfigOption calls can change it; they'd all need the escape
hatch.

            regards, tom lane