是否有说明支持哪些 PostgreSQL 数据库版本的文档？
如果能针对每个 Discourse 发布版本列出相关信息就太好了——尤其是当某个 PostgreSQL 版本不再受支持时。
Postgres 已随 Discourse 的 Docker 容器捆绑在一起，因此通常无需手动干预。Discourse 团队会在新版本发布且经过充分测试后升级 Postgres 版本。最近的升级已更新至 13 版。您可以在此处查看该升级的详细信息：
3 个赞
嗯，并非所有人都使用捆绑的 PostgreSQL 数据库。
当前安装文档列出所需版本为 Postgres 10+：
不过，唯一官方支持的部署方式是使用 Docker 容器。
2 个赞
是的，从 Docker 构建的角度来看（并非所有版本都“强力支持”），受支持的 PostgreSQL 版本列在 discourse_docker 的 templates 目录中：
不过，强烈建议您尽快迁移到最新的 PostgreSQL 版本，目前最新版本为 13。
但是，如果您所在的组织因某些本地限制而无法在主机上运行最新版本，那么 discourse_docker 的 templates 目录是一个很好的研究参考。
4 个赞
三年后检查：Docker 模板 仍然显示 PG_MAJOR=13，但有新版本的 PostgreSQL：14（来自 2021 年）、15（来自 2022 年）和 16（来自 2023 年）。
那么，建议仍然是使用 13 版本（将于 2025 年 EOL），而不是最新的 PostgreSQL 16（将于 2028 年 EOL）？
是的，没错。
我们已经有一些网站在使用15版本了，计划明年从13版本进行更新。
1 个赞
问题：这里目前的状况如何？我正在运行一个外部的 PostgreSQL 数据库，并希望将数据库服务器从 13 版本升级。PostgreSQL 16 于 2023-09-14 发布。它能与 Discourse 一起使用吗？数据库本身是否需要任何迁移步骤？（除了服务器端的全局迁移步骤之外）
PostgreSQL 13 仍是官方支持的版本，上个月发布的 13.15 版本仍在支持中。
我们有相当多的站点运行的是 15 版本，这是一个已知的可用版本，我们计划最终为自托管用户发布更新。
16 版本在开发人员机器之外并未得到广泛测试，但如果您想尝试一下，看看是否有东西会损坏，请告诉我们结果！
1 个赞
Discourse 是否对 Postgres 有什么特殊操作，这是否意味着升级到新版本的 Postgres 可能无法通过简单的转储和恢复来完成？
将此帖子置顶，看看是否有理由升级到 PostgreSQL 15 而不是 16 或 17？
我们何时应该期望升级 PostgreSQL
大家好，我刚迁移到 AWS RDS PostGre 16.4，似乎运行正常。
我使用的是 discourse 版本 3.4.0.beta3-dev
还没有点击所有按钮 
，但主板本身似乎运行正常，但是…
我无法创建备份，因为
[2024-12-13 08:36:07] 确保 '/var/www/discourse/tmp/backups/default/2024-12-13-083607' 存在...
[2024-12-13 08:36:07] 确保 '/var/www/discourse/public/backups/default' 存在...
[2024-12-13 08:36:07] 更新元数据...
[2024-12-13 08:36:07] 转储数据库的公共模式...
[2024-12-13 08:36:08] pg_dump: 错误：服务器版本：16.4；pg_dump 版本：13.18 (Debian 13.18-1.pgdg120+1)
[2024-12-13 08:36:08] pg_dump: 错误：由于服务器版本不匹配而中止
[2024-12-13 08:36:08] EXCEPTION: pg_dump 失败
奇怪的是，我实际上可以通过内部机制导入数据：
我做了什么：
- 设置数据库（用户、数据库、权限）
- 在 app.yml 中配置了设置
- 从 discourse 中创建了备份
- 重建应用程序（数据库迁移成功 → 数据库为空）
- 从容器内部恢复备份（launcher enter app, discourse enable_restore, discourse restore …）
- 完成（一切都成功了，并且一切似乎都正常工作，直到我尝试创建新的备份 :-)）
有什么办法可以解决这个问题吗？
问候，
JP
1 个赞
好的，各位，现在情况变得有趣了。
我几天没工作了，也没查看我们新的公司面板。
今天查看时，计划好的备份成功了，然后我尝试再次手动备份，结果失败了 
计划好的：
正在转储数据库的 public schema...
[2024-12-04 06:02:16] pg_dump: 上一个内置 OID 是 16383
[2024-12-04 06:02:16] pg_dump: 正在读取扩展
[2024-12-04 06:02:16] pg_dump: 正在识别扩展成员
[2024-12-04 06:02:16] pg_dump: 正在读取 schema
[2024-12-04 06:02:16] pg_dump: 正在读取用户定义表
[2024-12-04 06:02:16] pg_dump: 正在读取用户定义函数
[2024-12-04 06:02:16] pg_dump: 正在读取用户定义类型
......
pg_dump: 正在转储表 "public.themes" 的内容
[2024-12-04 06:02:19] pg_dump: 正在处理表 "public.top_topics" 的数据
[2024-12-04 06:02:19] pg_dump: 正在转储表 "public.top_topics" 的内容
[2024-12-04 06:02:19] 正在完成备份...
[2024-12-04 06:02:19] 正在创建归档： scp-talk-2024-12-04-060216-v20241127034553.tar.gz
[2024-12-04 06:02:19] 正在确保归档不存在...
[2024-12-04 06:02:19] 正在创建空归档...
[2024-12-04 06:02:19] 正在归档数据转储...
[2024-12-04 06:02:19] 正在归档上传...
[2024-12-04 06:02:19] 正在移除临时目录 '/var/www/discourse/tmp/backups/default/2024-12-04-060216'...
[2024-12-04 06:02:19] 正在 gzip 归档，这可能需要一些时间...
[2024-12-04 06:02:19] 正在为备份执行 after_create_hook...
[2024-12-04 06:02:19] 正在删除旧备份...
[2024-12-04 06:02:19] 正在清理...
[2024-12-04 06:02:19] 正在移除 '.tar' 剩余文件...
[2024-12-04 06:02:19] 正在标记备份完成...
[2024-12-04 06:02:19] 正在刷新磁盘统计信息...
[2024-12-04 06:02:19] 正在通知 '\u003cme\u003e' 备份结束...
手动：
[2024-12-16 10:03:54] '\u003cme\u003e' 已开始备份！
[2024-12-16 10:03:54] 正在标记备份运行中...
[2024-12-16 10:03:54] 正在确保 '/var/www/discourse/tmp/backups/default/2024-12-16-100354' 存在...
[2024-12-16 10:03:54] 正在确保 '/var/www/discourse/public/backups/default' 存在...
[2024-12-16 10:03:54] 正在更新元数据...
[2024-12-16 10:03:54] 正在转储数据库的 public schema...
[2024-12-16 10:03:54] pg_dump: 错误：服务器版本：16.4；pg_dump 版本：13.18 (Debian 13.18-1.pgdg120+1)
[2024-12-16 10:03:54] pg_dump: 错误：由于服务器版本不匹配而中止
[2024-12-16 10:03:54] 异常：pg_dump 失败
嗯嗯嗯，有什么想法吗？
非常奇怪 
我确认，升级到 3.4.0.beta3 并使用外部数据库会导致备份失败。
我有两个实例 3.4.0.beta3 (tag)：1) 使用 Postgres-in-Docker (默认)；2) 使用外部 Postgres (本地自托管)。
第一个实例可以按计划和手动进行备份：
[2024-12-23 11:11:43] Marking backup as running...
[2024-12-23 11:11:44] Making sure '/var/www/discourse/tmp/backups/default/2024-12-23-111143' exists...
[2024-12-23 11:11:44] Making sure '/var/www/discourse/public/backups/default' exists...
[2024-12-23 11:11:44] Updating metadata...
[2024-12-23 11:11:44] Dumping the public schema of the database...
[2024-12-23 11:11:44] pg_dump: last built-in OID is 16383
[2024-12-23 11:11:44] pg_dump: reading extensions
[2024-12-23 11:11:44] pg_dump: identifying extension members
[2024-12-23 11:11:44] pg_dump: reading schemas
...
第二个实例失败：
[2024-12-21 03:35:21] Marking backup as running...
[2024-12-21 03:35:21] Making sure '/var/www/discourse/tmp/backups/default/2024-12-21-033521' exists...
[2024-12-21 03:35:21] Making sure '/var/www/discourse/public/backups/default' exists...
[2024-12-21 03:35:21] Updating metadata...
[2024-12-21 03:35:21] Dumping the public schema of the database...
[2024-12-21 03:35:22] pg_dump: error: server version: 16.6 (Ubuntu 16.6-0ubuntu0.24.04.1); pg_dump version: 13.18 (Debian 13.18-1.pgdg120+1)
[2024-12-21 03:35:22] pg_dump: error: aborting because of server version mismatch
[2024-12-21 03:35:22] EXCEPTION: pg_dump failed
...
2 个赞
我昨天已升级，并确认计划的备份由于版本不匹配而失败。
您可以通过进入 Docker 并安装更新的 postgresql-client 来修复。
/var/discourse/launcher enter app
apt update
apt install postgresql-client
2 个赞
大家好，
我现在已经切换到 RDS 中的加密 PostGre 数据库，昨天我也做了同样的事情（就像我在前面步骤中描述的那样（进行备份、编辑 app.yml、重建，…），昨天它还能正常工作。
今天我尝试对 PROD 进行操作，现在我收到了这个错误
正在创建 discourse_functions schema 中缺失的函数…
正在恢复 dump 文件… （这可能需要一些时间）
SET
SET
SET
错误：无法识别的配置参数“transaction_timeout”
异常：psql 失败：错误：无法识别的配置参数“transaction_timeout”
我尝试直接在 DBeaver 中对数据库进行操作，我遇到了同样的错误（即使对于昨天还能完美工作的那个数据库也是如此。
在两种情况下，备份都是最新的。
你们昨晚有更改什么吗？ 
谢谢，祝好，
WS
您好，
检查了备份文件中正在进行的转储：
它在顶部包含以下内容：
SET statement_timeout = 0;
SET lock_timeout = 0;
SET idle_in_transaction_session_timeout = 0;
SET transaction_timeout = 0;
SET client_encoding = ‘UTF8’;
SET standard_conforming_strings = on;
这里的 transaction_timeout 参数很奇怪 因为
transaction_timeout 是在 PostgreSQL 17 中添加的。
如下所述：
https://pgpedia.info/t/transaction_timeout.html
需要帮助
谢谢！
此致，
Wurzelseppi
1 个赞
是否有一种方法可以将此 postgresql-client 更新作为重建的一部分进行自动化，方法是修改容器 yaml？