确实如此，但我们的目标是实现一个简单透明的升级机制。两种方式各有优劣。
我会说，按照你觉得舒服的方式去做即可，不要害怕根据你的需求自定义 discourse_docker 中的模板。显然，关键在于先进行测试并制定回滚计划。
在我们托管平台上，我们打算在启用这些功能之前进行更多的测试和基准测试，因此我同样在 discourse_docker 中禁用了它们以保持一致。不过，严格来说并没有必要禁用它们（我们内部仅使用 discourse_docker 的 Web 容器部分），我也不反对启用它们。
一个潜在的陷阱是，如果旧数据目录和新数据目录的校验和设置不同，pg_upgrade 将无法工作。流程必须是：关闭 PG15 服务器，运行 pg_upgrade 将其转换为无校验和的 PG18，运行 pg_checksums 启用校验和，然后启动 PG18。在使用转储和恢复（如此次升级）时这不是问题，但需要注意这一点。
请注意，数据校验和自 Postgres 9.3 起就已可用，但直到目前为止默认都是禁用的。Postgres 19 还将包含在线启用/禁用它们的能力。
[quote=“elmuerte, post:25, topic:406194, full:true”]
只是为了确认，我没有使用 Discourse 提供的 PostgreSQL，而且 Discourse 本身目前还不要求使用 PG18，对吧？所以我目前（还）不需要升级到 PG18。
[/quote]\n
目前确实如此。大多数 Discourse 功能使用 Rails PostgreSQL 适配器与数据库通信，但备份/恢复使用 Web 容器中的 pg_dump 和 psql。目前我们同时安装了 PG15 和 PG18 客户端，以支持使用这两个版本进行备份/恢复，但在未来的某个时间点，我们将移除 PG15。
主要驱动因素是切换到新的内置区域设置（locale）提供程序。我们正在致力于托管平台的操作系统升级，并希望打破与 glibc 的耦合。