有时，最小的补丁也会引起最大的讨论。PostgreSQL 社区（通常不是一个容易产生冗长、措辞激烈的大型讨论的群体）解决是否合并一个添加了新配置参数的简短补丁的问题，就是一个很好的例子。有时，看似安全补丁的提议实际上并不是安全补丁，但要表达出这一点却很困难。
PostgreSQL 服务器是一个复杂的系统，可以根据运行环境进行大量配置和调整。自然，有许多配置参数可供管理员使用。设置这些参数也有两种方法。在大多数部署中，管理员可能会编辑 postgresql.conf 文件，根据需要配置系统。不过，也可以使用 ALTER SYSTEM 命令在运行的数据库中调整参数。通过这种方式做出的任何更改都将保存到单独的 postgresql.auto.conf 文件中，服务器在启动时也会读取该文件；因此这些更改是持久的。
禁用 ALTER SYSTEM
2023 年 9 月初，加布里埃尔-巴托里尼（Gabriele Bartolini）提出了允许管理员禁用 ALTER SYSTEM 的想法，可以通过命令行参数或配置选项来禁用（用 PostgreSQL 术语来说，他称之为 “GUC”，即 “大统一配置 “参数）。
主要原因是，这将有助于改善PostgreSQL在Kubernetes/云原生环境中的 “默认安全 “态势–一般来说，也有助于改善在配置管理系统背后的虚拟机/裸机环境中的 “默认安全 “态势。
PostgreSQL 核心贡献者汤姆-莱恩（Tom Lane）很快表达了他对这一提议的不同意见：”我不认为我们需要在权限系统中加入随机的 kluges。我尤其不相信’超级用户不再拥有所有权限’这样的klug”。他建议，如果真的需要，可以使用事件触发器在本地实施这种限制。
Alvaro Herrera 指出，ALTER SYSTEM 作为全系统范围的命令，不会调用事件触发器。他还更透彻地解释了驱动这一请求的用例：
我在书上看到，使用容器的人看待服务的角度与我们以往看待服务的角度不同；他们说服务是 “牲口，不是宠物”。
postgresql.conf（实际上是所有 PG 配置）只是整个系统描述中的一个派生文件，它存在于数据库服务器之外。你不再逐个喂养 PG 服务器，而是让它们像羊群一样行动，而放牧者就是某个容器监管者（不管它叫什么）。确保配置状态不能从内部改变对于维护服务的完整性非常重要。如果用户想更改配置，可以使用外部工具。
不过，Lane 将该功能描述为 “虚假的安全”，于是讨论暂时告一段落。但根本的分歧已经显露出来：反对限制ALTER SYSTEM的观点是基于它是一项安全功能。因此，它是失败的，因为有很多其他方法可以让有能力运行 ALTER SYSTEM 的 PostgreSQL 用户控制服务器。但是，正如 Bartolini 所说，这一限制的目的是作为一种可用性功能，关闭一种配置机制，而这种机制并不适合在声明式配置系统中使用。
新的一年
罗伯特-哈斯（Robert Haas）在 1 月份重新启动了对话，承认该提案并非作为一种安全功能，但担心无论如何都会被视为一种安全功能：
我不得不承认，我有点担心人们会误以为这是一项真正的安全功能，并提交关于超级用户可以规避这些限制的错误报告或 CVE。如果我们添加了这个功能，我们最好确保在文档中非常清楚地说明我们保证了什么，或者更明确地说明我们没有保证什么。
即便如此，他还是担心 “安全研究人员威胁要在 Register 上公布我们的邪恶”。莱恩随后宣布，该项目 “不仅应该拒绝这项提案，而且还应该拒绝今后任何打算阻止超级用户做超级用户通常可以做的事情的提案”。哈斯回应说，最初的提议可能有其道理，应该认真对待。
讨论没有结果；两个月后，哈斯抱怨说进展不大。尽管如此，他还是说”就我所看到的主题而言，大多数人都认为有某种方法禁用 ALTER SYSTEM 是合理的。不过，有六种相互竞争的方法可以实现这一目标。其中包括最初提出的命令行选项和配置参数，以及事件触发器、将其推入扩展模块、识别管理员创建的哨兵文件，或者只是更改 postgresql.auto.conf 的权限。他认为配置选项和哨兵文件是最可行的方案。
Lane 回答说，通过上述任何一种机制实施的任何此类限制，仍有可能被怀有敌意的管理员绕过。Haas 回答说，该建议并不是一项安全功能，但 Lane 将其斥之为 “用孩子们喜欢的颜色涂抹的装满子弹的脚枪”，这将导致更多针对该项目的虚假 CVE 编号被提交。
新补丁
3 月 15 日，Jelte Fennema-Nio 发布了一个补丁，以配置参数的形式实现了限制。归根结底，这只是 Bartolini 在 9 月份发布的补丁的更新版本，并对文档进行了一些调整。几天后，第六个版本发布。此时，补丁主要由文档组成，其中包括以下告诫：
请注意，此设置不能被视为一项安全功能。它只能禁用 ALTER SYSTEM 命令。它并不能阻止超级用户使用其他手段远程更改配置。
哈斯对这一版本表示欢迎，并询问大家是否就继续使用这一版本达成共识。这时，莱恩似乎有些改变了看法，他说：”我从来没有反对过这个想法：”我从未反对过禁用 ALTER SYSTEM 的想法。而 Bruce Momjian 则担心，管理员可能会输入一条 ALTER SYSTEM 命令，禁用 ALTER SYSTEM，这样就很难恢复了。事实上，正如 Fennema-Nio 所回答的那样，该参数不能这样设置，因此这种陷阱并不存在。
Momjian 还对参数的名称（即 externally_managed_configuration）提出了异议，认为它没有真正描述限制的内容。他建议使用 sql_alter_system_vars 作为替代。哈斯同意他的抱怨，但认为 allow_alter_system 更有意义。最终，该选项就采用了这个名称。
但讨论还没有结束。Lane 希望服务器能确保在禁用 allow_alter_system 的情况下，postgres 用户不能写入 postgresql.conf 和 postgresql.auto.conf。否则，数据库管理员仍然可以通过编辑其中一个文件来修改配置。Fennema-Nio 不同意这种说法，他认为禁用 ALTER SYSTEM 就足以满足预期的使用要求，但 Lane 却说，配置参数本身就是 “一张无花果叶，也许能骗过不称职的审计员，但仅此而已”。Fennema-Nio 提醒 Lane，allow_alter_system 的重点不是安全性。哈斯抱怨说”哈斯抱怨说：”我不明白为什么那些憎恨这项功能并希望它葬身火海的人可以决定它的工作方式。文件权限检查最终没有被添加。
即便如此，讨论仍未完全结束；Momjian 对在 PostgreSQL 开发周期如此之晚才合并这一变更提出了质疑。”我的观点是，我们是在提交节的最后几周才设计用户应用程序接口的，这通常会给我们带来不好的结果。Fennema-Nio 指出，API 与九月份的最初版本相比基本没有变化，而且我们已经花了几个月的时间讨论替代方案。哈斯说，这样一个小补丁再拖到另一个发布周期也不会有什么改进：”我认为，在我们都在思考这个问题，而且每个人都对这个问题记忆犹新的时候，完成这个补丁是正确的。
3 月 28 日，Momjian 同意合并补丁。一天后，哈斯就这样做了。至此，PostgreSQL 历史上持续时间最长的开发讨论之一宣告结束。这项工作的成功证明了少数开发人员的坚持不懈，他们在数月的反对声和 “有益的 “实施建议中坚持了下来。在解决了这个棘手的问题之后，该项目可以将注意力转移到即将到来的七月提交节期间要解决的一小部分简单问题上了。
你的反应是：