### Describe the bug 在部署后的隔离备份恢复检查中,发现官方 v15.6.1 镜像与同版本 Compose 指定的 PostgreSQL 16 存在兼容问题。该问题由 Codex 辅助检查发现,并通过实际数据库实验复现;未对生产数据执行恢复。 镜像内的 `pg_dump` / `pg_restore` 为 PostgreSQL 18.6,生成的恢复 SQL 含有 `SET transaction_timeout = 0;`,但数据库服务端为 PostgreSQL 16.14,不识别该参数。 预期:官方部署组合生成的备份可以正常恢复。 实际:数据库恢复阶段报错退出。该发布版本使用单事务与 `ON_ERROR_STOP`,因此恢复事务回滚,后续文件恢复不会继续。 ```text ERROR: unrecognized configuration parameter "transaction_timeout" psql exit status: 3 ``` **源码和运行环境核验** 已核对镜像 OCI 标签对应提交 `01b23b944e97e388b8c4bf7a854b1f92d163f15f`,并确认运行编译包中的恢复命令与该提交一致: - [docker-compose.yml](https://github.com/mx-space/core/blob/01b23b944e97e388b8c4bf7a854b1f92d163f15f/docker-compose.yml) 使用 `postgres:16-alpine`。 - [dockerfile](https://github.com/mx-space/core/blob/01b23b944e97e388b8c4bf7a854b1f92d163f15f/dockerfile) 安装未固定主版本的 `postgresql-client`。 - [backup.service.ts](https://github.com/mx-space/core/blob/01b23b944e97e388b8c4bf7a854b1f92d163f15f/apps/core/src/modules/backup/backup.service.ts) 通过 `pg_restore --file` 导出 SQL,再用 `psql --single-transaction --set=ON_ERROR_STOP=on` 执行。 备份生成与 S3 上传都成功;错误发生在恢复 SQL 的执行阶段。归档可被读取,对照实验也能导入,因此没有据此判断备份损坏。 未发现同一错误的已有报告。#2856 是初始化入口的加密备份格式/密钥问题;#2679 是 PostgreSQL 主版本升级 PR,与这里的恢复兼容性报告不同。暂不提交修复 PR。 ### Reproduction 以下实验使用真实内置备份,在独立临时数据库完成,没有调用生产恢复 API: 1. 在官方 v15.6.1 镜像和 PostgreSQL 16 环境中生成内置备份 ZIP,取出 `mx-space/pg.dump`。 2. 用应用镜像中的 PostgreSQL 18.6 客户端导出 SQL: ```sh pg_restore --clean --if-exists --no-owner --no-acl --file restore.sql pg.dump ``` 其中包含 `SET transaction_timeout = 0;`。 3. 在 PostgreSQL 16 的专用临时数据库中创建一行前哨数据: ```sql CREATE TABLE independent_sentinel (id integer); INSERT INTO independent_sentinel VALUES (1); ``` 创建 `prepare.sql`,内容为: ```sql DROP TABLE independent_sentinel; ``` 4. 在该临时数据库中按内置恢复的事务及错误处理方式执行: ```sh psql --no-psqlrc --single-transaction --set=ON_ERROR_STOP=on \ --dbname <temporary-database> --file prepare.sql --file restore.sql ``` 结果为上述 `transaction_timeout` 错误、退出码 3。前哨表和一行数据仍存在,确认事务回滚。 5. 对照实验只移除 `restore.sql` 中的 `SET transaction_timeout = ...` 行,同一份归档成功导入,退出码 0。随后删除临时数据库。 这是数据库命令层面的隔离复现,未完成整个 UI/API、文件复制和缓存恢复的端到端测试。内置流程还会生成 `runtime-schema.sql`;对照实验不构成可直接投产的完整修复,修复需覆盖所有客户端生成的 SQL。 ### System Info ```text Deployment: Docker on Debian 13, linux/amd64 Core: v15.6.1 Core revision: 01b23b944e97e388b8c4bf7a854b1f92d163f15f Core image: innei/mx-server@sha256:91bf5a843c3137511bcee6ac5e690bec02ce8568be1bc20d9150d6d6688dcddf Node (inside Core): v26.12.1 pg_dump / pg_restore (inside Core): PostgreSQL 18.6 Database image: postgres:16-alpine Database server: PostgreSQL 16.14 ``` ### Validations - [x] Follow our [Code of Conduct](https://github.com/mx-space/.github/blob/main/CODE_OF_CONDUCT.md) - [x] Read the [Contributing Guide](https://github.com/antfu/contribute). - [x] Check that there isn't already an issue that reports the same bug to avoid creating a duplicate. - [x] Check that this is a concrete bug. For Q&A, please open a GitHub Discussion instead. - [x] The provided reproduction is a [minimal reproducible](https://stackoverflow.com/help/minimal-reproducible-example) of the bug.
Activity
linear commentedon Oct 28, 2026
MXD-253