Improving GUC prefix ownership for extensions
Hello!
MarkGUCPrefixReserved already attempts to mark a GUC prefix as owned
by a specific shared library, but it only works partially: it removes
remaining placeholders and emits an error if a later extension tries
to use the same prefix.
What it does not do:
* It does not detect the case where an extension loaded earlier
already used something in that prefix, since there is currently no way
to tell who declared a GUC variable before the prefix was reserved.
* It does not enforce that an extension actually uses only its
reserved prefixes.
Both caused by the fact that this is an after-the-fact marker, not
something that extensions have to setup before declaring variables.
Since the intent of the function seems to be defining proper GUC
prefix ownership for extensions—and since it would be good practice
for extensions to follow this—I created a patch that improves this
behavior.
I didn't want to enforce anything by default, so this is controlled by
a GUC variable:
* The default is currently "off", which preserves the existing behavior.
* "warning" generates warnings if:
** an extension used a reserved GUC prefix before another extension
reserved it,
** an extension does not register any reserved prefixes, or
** it declares a GUC variable outside its reserved prefixes.
* "prefix" keeps the warning if an extension does not reserve a
prefix, but turns the other issues into errors.
* "enforce" makes all of the above errors.
I am not sure whether introducing another GUC is the best solution,
but it is the best option I have found so far. The alternative would
be to change the GUC API in some way—for example, by adding a new
version of MarkGUCPrefixReserved, or an additional
MakeSureGUCPrefixIsEmpty function that would opt an extension into
stricter behavior. That approach would shift control from database
administrators to extension developers; to me, giving administrators
control seems preferable.
At the moment, the default is "off", but perhaps it should be
"warning". My hope is that the default strictness could increase over
a few major releases.
Currently, the patch does not restrict what the prefix can be, nor the
number of prefixes. Restricting the number does not seem practical, as
there are already extensions (including some in contrib) that reserve
multiple prefixes. However, would it make sense to enforce that a
prefix must either match the library name or start with it? Possibly
as a separate option?
Thoughts, would this be a useful feature?
Attachments:
0001-Guc-prefix-enforcement.patchapplication/octet-stream; name=0001-Guc-prefix-enforcement.patchDownload+677-7
On Wednesday, February 11, 2026, Zsolt Parragi <zsolt.parragi@percona.com>
wrote:
Thoughts, would this be a useful feature?
I’d go with leaving well enough alone. How bad are the consequences of
leaving this protection mechanism opt-in? Do we really want the grief of
making it mandatory?
David J.
Do we really want the grief of making it mandatory?
I didn't suggest making it mandatory - the current patch I attached is
completely opt-in (default setting is exactly how it works currently,
DBAs have to opt in by changing it).
What I mentioned is that we could make it opt-out
1. by making the warning the default, which still allows everything
allowed currently, and doesn't change behavior at all, other than
writing a few warnings to the logs
2. and later maybe changing it to a more strict default, but still
keeping the GUC, so users can opt out
But that part is optional, we could simply leave it completely relaxed
by default.
My reasoning for making the warning the default is to encourage
extension developers to properly reserve GUC prefixes, without causing
compatibility problems for users - but I'm not sure about that, that's
why I submitted the patch with "off" default.
On Wednesday, February 11, 2026, Zsolt Parragi <zsolt.parragi@percona.com>
wrote:
Do we really want the grief of making it mandatory?
I didn't suggest making it mandatory - the current patch I attached is
completely opt-in (default setting is exactly how it works currently,
DBAs have to opt in by changing it).My reasoning for making the warning the default is to encourage
extension developers to properly reserve GUC prefixes, without causing
compatibility problems for users - but I'm not sure about that, that's
why I submitted the patch with "off" default.
The fact users can set this to strict effectively makes variable
registration mandatory for extension authors, not merely “encouragement”,
IMO. That’s a decent step-up from “protect thyself” to “user-mandated”.
I’m just not seeing enough benefit here to provoke three-way discussions
between users, extension authors, and ourselves. Rather leave well-enough
alone given current information about the community’s experiences in this
realm.
David J.
"David G. Johnston" <david.g.johnston@gmail.com> writes:
On Wednesday, February 11, 2026, Zsolt Parragi <zsolt.parragi@percona.com>
wrote:Thoughts, would this be a useful feature?
I’d go with leaving well enough alone. How bad are the consequences of
leaving this protection mechanism opt-in? Do we really want the grief of
making it mandatory?
Making it mandatory is a non-starter, and the only thing that could
be even worse than that is having it GUC-controlled (remembering that
extension authors have to cope with all possible GUC settings).
I don't think this idea can fly. I'm also skeptical that there's any
real-world problem that needs solving here. I've not heard reports of
GUC prefix conflicts between extensions --- that would pretty much
imply an extension name conflict, which is problematic with or without
any GUCs. What MarkGUCPrefixReserved is really about is detecting
misspelled hand-made config-file entries and SET commands as best we
can. It's not perfect certainly, but I don't see that this proposal
makes that case better.
regards, tom lane
What MarkGUCPrefixReserved is really about is detecting
misspelled hand-made config-file entries and SET commands as best we
can.
That's not strictly true, MarkGUCPrefixReserved already implements part of this:
1. If extension A reserves prefix "ext_a"
2. And then extension B tries to register a GUC named "ext_a.something"
We get an error.
But if these extensions are loaded in the opposite order, everything
works fine, extension B can use a variable in a prefix reserved by
another extension.
If I remove the part about requiring MarkGUCPrefixReserved prefix /
printing a warning if it's not called, all this patch does is makes
the behavior of MarkGUCPrefixReserved more consistent.
My initial goal was simply that (to print out an error even if things
happen in a different order), but then I thought maybe also nudging
extensions towards reserving prefixes with MarkGUCPrefixReserved would
be useful.
I'm also skeptical that there's any
real-world problem that needs solving here
This came up based on a discussion on how MarkGUCPrefixReserved works,
and what exactly does it prevent, because it's not really
consistent/intuitive currently. I personally thought that it already
enforces that only that extension can use the prefix, and I was
surprised when I discovered that it is only half true.
What do you think about a simplified version, which only solves the
original problem - properly reporting errors regardless of the order
of library loading, if MarkGUCPrefixReserved is used?