Redshift Copy命令报错：无法打开OID 591927的关系求助

针对你遇到的AWS Glue Spark代码执行Redshift Copy时特定表报错Exception: ERROR: could not open relation with OID 591927的问题，结合你的测试结果，给出以下排查步骤：

1. 核对权限差异 #

• 确认Glue作业使用的IAM角色对应的Redshift数据库用户，是否拥有目标表的TRUNCATE和INSERT权限。即使其他表正常，该表的权限可能在11月1日被调整（比如撤销后未重新授权）。
• 对比DBeaver使用的账号与Glue角色对应用户的权限：执行SELECT * FROM pg_user WHERE usename = 'Glue对应的用户名';和SELECT has_table_privilege('Glue用户名', 'schema.表名', 'truncate'), has_table_privilege('Glue用户名', 'schema.表名', 'insert');，确保权限齐全。

2. 验证OID与表元数据 #

• 先确认报错的OID 591927对应的对象：执行SELECT relname, relkind, nspname FROM pg_class JOIN pg_namespace ON pg_class.relnamespace = pg_namespace.oid WHERE pg_class.oid = 591927;，看是否是目标表。如果不是，说明表可能被重建（DROP后新建、TRUNCATE RESTART IDENTITY等）导致OID变更，而Glue代码可能缓存了旧OID。
• 检查目标表元数据是否正常：执行SELECT * FROM pg_tables WHERE tablename = '你的表名' AND schemaname = '你的schema';，确认表存在且状态正常，没有被标记为无效。

3. 排查Glue元数据缓存 #

• Glue作业默认会缓存元数据，若表OID变更后缓存未更新，会导致报错。可以：
  • 在Glue作业的Spark配置中添加spark.sql.hive.metastore.cache.expiryInterval=0禁用缓存；
  • 在代码中显式刷新表元数据：spark.catalog.refreshTable("schema.表名")，再执行Copy命令。
• 检查代码中是否存在硬编码OID的逻辑，比如有没有通过OID引用表的语句。

4. 对比Copy命令执行上下文 #

• 打印Glue代码中生成的完整Copy命令，与DBeaver中执行的命令逐字符对比，重点检查：
  • 表名的大小写（Redshift大小写敏感，若代码中表名与实际表名大小写不一致，可能导致OID匹配失败）；
  • TRUNCATE选项的位置、S3路径、IAM角色ARN是否正确；
  • 是否包含额外参数（比如FORMAT AS PARQUET等），导致执行逻辑差异。

5. 检查Redshift集群近期变更 #

• 查看11月1日前后Redshift集群的操作记录：是否有版本升级、重启、VACUUM/ANALYZE操作？这些操作可能导致表元数据或OID变化。
• 查看Redshift系统日志（CloudWatch或集群日志），搜索OID 591927相关条目，获取更详细的错误触发阶段（是TRUNCATE还是Copy步骤报错）。

6. 最小化场景测试 #

• 编写极简Glue作业：仅初始化Spark会话、获取Redshift连接、执行目标表的TRUNCATE+Copy命令，排除循环逻辑、状态检查等干扰项，看是否仍报错。
• 使用超级用户对应的IAM角色运行该极简作业，验证是否为权限问题。

内容的提问来源于stack exchange，提问作者Aakash Basu