注意：原因尚不明确，但PostgreSQL 18 升级禁用了原生数据校验和。PostgreSQL 数据校验和是默认功能，禁用它似乎非常不寻常。
PR 以不禁用数据校验和（默认启用）：Do not disable PostgreSQL 18 data checksums - Pull Request #1105 - discourse/discourse_docker - GitHub
而且这比为了在一年内使用1小时而需要预留20GB空间要好多了，哈哈
也许这应该成为推荐的做法，以节省树木和水资源。
只是为了确认，我并没有使用 Discourse 提供的 PostgreSQL，而且 Discourse 本身目前也不要求 PG18，对吧？所以我暂时不需要升级到 PG18。
说得好。但另一点是，LTS（长期支持）版本每两年发布一次，所以趁此机会一并处理也是个不错的主意。
你确实还有很长一段时间。因为某个必需的功能，他们在更新后很快推动了……呃，某个版本的发布，但你很可能可以等待长达一年。我会关注 discourse_docker 仓库。他们迟早会开始讨论移除对 PG15 的支持；这方面的动静不大，是跟踪内部更新的一个简便方法。
2 个赞
在我的 Pi 5 安装上运行正常，重建两次就搞定了。
6 个赞
顺便问一下，我们有任何基准测试数据吗？
这可能会鼓励其他人 sooner 跟随我们无畏的脚步。
我的免费网页搜索 AI 告诉我：
对于典型的 Rails 应用，从 PostgreSQL 15 升级到 18 可以在不更改代码的情况下带来 ~10–25% 的查询性能提升，如果充分利用新的索引和规划器功能，在特定查询模式下甚至可提升 高达 40%。
如果属实，那真是相当不错的升级！
7 个赞
只是确认一下，我们自托管的实例一切运行完美。感谢这次更新，请继续通知我们。
4 个赞
确实如此，但我们的目标是实现一个简单透明的升级机制。两种方式各有优劣。
我会说，按照你觉得舒服的方式去做即可，不要害怕根据你的需求自定义 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 的耦合。
2 个赞
我独立于容器管理我的 PostgreSQL。切换到 pg18 时，推荐使用的 Git 哈希值是多少？
1 个赞
e7f1201 为备份兼容性向 Web 镜像添加了 PG18 客户端。如果您未使用 discourse_docker 的任何 Postgres 服务器组件，则 PG18 应使用此最早的修订版本。
1 个赞
我指的是前一次或两次升级。
同意。我的观点仅仅是，能够将较旧的 PostgreSQL 备份恢复到较新版本中，其支持程度并不更低。原地升级机制对绝大多数用户来说效果极佳，但当出现问题时，很难知道该如何处理（主要是因为这种情况很少发生）。
2 个赞
如果这对任何人有帮助，在 SSH 控制台静止不动、冷汗开始冒出的那些时刻……
我在另一个终端中运行了以下命令，以便监控进度：
watch -n 10 'df -h /; echo; du -sh /var/discourse/shared/standalone/postgres_data* 2>/dev/null'它会每 10 秒更新一次，让你保持理智
我的 35GB 迁移大约花了 10 分钟。
8 个赞
更新在我的标准安装过程中顺利进行。当然，在此之前我还做了一个备份并下载了，以防万一出现什么问题 
3 个赞
不错。我会在那里加上 free -h——内存不足是一个相当常见的问题。
关于 watch 或 top 的唯一问题是，它会不断刷新，所以你可能会错过一些信息。如果你用完了某种资源并且更新失败，几秒钟后你就丢失了记录。所以我倾向于运行更像 while 的东西——也许像这样：
while true; do date; echo; free -h; echo; df -h /; echo; sh -c 'du -sh /var/discourse/shared/standalone/postgres_data* 2>/dev/null'; sleep 10; echo; done
4 个赞
我可以报告成功……在我多站点设置的一半上。默认站点按预期迁移，但次要站点看起来像是一个全新安装。幸运的是，恢复备份并不难。我有另一台用于客户的服务器，我打算启动一个新的 Droplet 并从备份中恢复站点以进行此更新。我想，这是使用非标准安装的风险之一。
1 个赞
你的数据容器是标准的数据容器吗？我一直在想，它只会迁移一个数据库还是集群中的所有数据库。听起来你已经回答了这个问题！
我一直在做的是手动将每个数据库从旧集群迁移到新集群，然后手动编辑 discourse.conf 以指向新数据库，接着执行重建，使整个多站点容器指向新集群（在不同的机器或端口上）。
1 个赞
是的。当然，我不能保证我的配置没有任何失误。
我原本计划使用 rsync 同步我的 PostgreSQL 数据，以便在那里运行 qn 升级，从而确切地查看该过程是仅迁移了 Discourse 数据库还是整个集群。但听起来你似乎已经回答了这个问题，而且如果我查看代码的话，这一点将会很清晰。
2 个赞
这里有两个问题：
- 我们在测试服务器上挂载了一个额外的存储块。但由于空间检查仅检查主磁盘，PostgreSQL 升级失败。有没有办法绕过空间检查？
- 对于我们的生产站点，我们使用 Google Cloud SQL。在通过 Google Cloud 进行升级之前，有什么需要知道的吗？