AWS RDS Postgres 13.12与TypeORM适配报错求助

问题背景与报错详情 #

初始报错（TypeORM 0.2.19） #

使用AWS RDS Postgres 13.12搭配Node.js TypeORM 0.2.19时触发错误：

error: { error: column cnst.consrc does not exist
query failed: SELECT "ns"."nspname" AS "table_schema", "t"."relname" AS "table_name", "cnst"."conname" AS "constraint_name", CASE "cnst"."contype" WHEN 'x' THEN pg_get_constraintdef("cnst"."oid", true) ELSE "cnst"."consrc" END AS "expression", CASE "cnst"."contype" WHEN 'p' THEN 'PRIMARY' WHEN 'u' THEN 'UNIQUE' WHEN 'c' THEN 'CHECK' WHEN 'x' THEN 'EXCLUDE' END AS "constraint_type", "a"."attname" AS "column_name" FROM "pg_constraint" "cnst" INNER JOIN "pg_class" "t" ON "t"."oid" = "cnst"."conrelid" INNER JOIN "pg_namespace" "ns" ON "ns"."oid" = "cnst"."connamespace" LEFT JOIN "pg_attribute" "a" ON "a"."attrelid" = "cnst"."conrelid" AND "a"."attnum" = ANY ("cnst"."conkey") WHERE "t"."relkind" = 'r' AND (("ns"."nspname" = 'dbname' AND "t"."relname" = 'users'))

本地环境中schema内无表时会触发该错误，原因是Postgres 12+版本已移除pg_constraint表的consrc字段，改用pg_get_constraintdef()函数，但旧版TypeORM仍在使用废弃字段。

升级TypeORM后的新报错 #

将TypeORM升级至0.2.45或0.3.6后，本地问题解决，但开发服务器出现新错误：

QueryFailedError: relation "dbname.datamod" does not exist

      at new QueryFailedError (src/error/QueryFailedError.ts:9:9)
      at Query.callback (src/driver/postgres/PostgresQueryRunner.ts:178:30)
      at Query.handleError (node_modules/pg/lib/query.js:146:19)
      at Connection.connectedErrorMessageHandler (node_modules/pg/lib/client.js:236:17)
      at Connection.emit (node:events:513:28)
      at Connection.emit (node:domain:489:12)
      at Socket.<anonymous> (node_modules/pg/lib/connection.js:121:12)
      at Socket.emit (node:events:513:28)
      at Socket.emit (node:domain:489:12)
      at addChunk (node:internal/streams/readable:315:12)

更高环境同配置可正常运行，仅开发服务器存在该问题。

解决步骤 #

1. 确认TypeORM升级的有效性 #

TypeORM 0.2.34及以上版本已修复Postgres 12+的pg_constraint字段兼容问题，替换consrc为pg_get_constraintdef()，所以升级到0.2.45/0.3.6是正确操作，本地问题解决已验证这一点。

2. 排查开发服务器的表不存在问题 #

针对仅开发环境出现的错误，按以下顺序排查：

• 检查schema配置：确认TypeORM配置文件中的schema字段是否正确指向dbname，或实体类是否通过@Entity({ schema: "dbname" })指定了正确schema。
• 验证数据库初始化状态：对比生产环境的迁移记录，确认开发服务器已执行所有必要的迁移命令（如typeorm migration:run），确保datamod表已创建。
• 检查数据库权限：确认开发环境使用的数据库账号拥有dbname schema及datamod表的访问权限，可执行以下命令授权：

  GRANT ALL ON SCHEMA dbname TO your_db_user;
  GRANT ALL ON TABLE dbname.datamod TO your_db_user;
  

• 核对连接字符串：确认开发环境的数据库连接字符串是否指定了默认schema，Postgres可通过options=schema=dbname参数设置，例如：

  postgresql://user:pass@host:port/db?options=schema%3Ddbname
  

• 清除TypeORM元数据缓存：执行typeorm cache:clear清除缓存，然后重启服务，避免旧元数据导致的表定位错误。
• 检查Postgres的search_path配置：查询开发服务器的search_path设置：

  SHOW search_path;
  

  若dbname不在列表中，执行以下命令修改：

  ALTER ROLE your_db_user SET search_path TO "$user", public, dbname;
  

3. 替代方案（无需降级Postgres） #

由于更高环境同配置正常，降级Postgres并非最优解。若上述步骤无效，可尝试：

• 重新创建开发环境数据库，确保与生产环境的schema、表结构完全一致。
• 检查开发环境的环境变量是否正确，避免因变量错误导致连接到错误的数据库或schema。

内容的提问来源于stack exchange，提问作者Rutunj sheladiya