Is there somewhere a note, which postgresql db versions are supported?
Would be great to have something for each released discourse version - especially if a postgresql version is no longer supported.
Postgres is bundled in with the Docker container for Discourse, so this is generally hands-off. The Discourse team upgrades the Postgres version as new releases come out and they are properly tested. The most recent upgrade was to version 13. You can see the details of that upgrade here:
3 个赞
Well, not everyone is using the bundled postgres db.
The current install doc lists Postgres 10+ as the required version:
https://github.com/discourse/discourse/blob/master/docs/INSTALL.md
That said, the only officially supported setups are using Docker containers.
2 个赞
Yes, the versions of postgres which are “supported” (from a docker build perspective, not all “strongly supported”) are listed in the templates directory of discourse_docker
Having said that, it is highly recommended to move to the latest version of postgres, currently version 13, as soon as you can.
However, if you are running Discourse on a host where you cannot run the latest version because of some local constraint in your organization; the discourse_docker templates directory is a good place to research.
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
是否有一种方法可以将此 postgresql-client 更新作为重建的一部分进行自动化，方法是修改容器 yaml？