AWS Lambda调用Redshift报错：无法打开OID为26223345的关系

OID归属 #

这个OID绝对属于Redshift，Lambda没有这类用于标识数据库关系对象的OID。Redshift用OID唯一标记数据库内的表、视图、索引、序列等对象。

为什么查不到这个OID？ #

• 对象已被删除：报错发生时或两次触发的间隔期，对应OID的表/视图被其他操作（比如手动清理、其他ETL任务）删除了，当前数据库中自然找不到该OID的记录。
• 临时对象已销毁：如果流程依赖临时表，临时表仅在创建它的会话生命周期内存在，会话结束后自动销毁，OID也随之消失。
• 查询范围不全：你可能只查询了public schema下的对象，而该OID对应的对象属于其他schema；或者查询语句没有正确关联系统表字段，导致遗漏。

报错的核心原因 #

• 并发操作冲突：Lambda触发的处理流程执行时，另一个任务（比如定时清理脚本、手动维护）刚好删除/修改了依赖的对象，导致当前SQL找不到目标对象。
• 临时表生命周期不匹配：流程中使用的临时表是在其他会话创建的，或者当前会话内临时表被提前销毁，后续SQL执行时找不到对象。
• 对象改名：目标对象被重命名，旧OID对应的对象条目被移除，新对象有新的OID。

解决办法 #

排查步骤 #

1. 定位关联SQL：查看CloudWatch中Lambda的完整执行日志，找到报错时正在运行的SQL语句，明确依赖的对象。
2. 查询删除记录：用Redshift系统表stl_drop查找被删除的对象信息，执行：

   SELECT objname, schemaname, droptime, username FROM stl_drop WHERE objoid = 26223345;
   

   该表会记录所有被删除对象的详细信息，能帮你找到删除操作的执行者和时间。
3. 全schema查询对象：如果怀疑对象在其他schema，执行以下语句覆盖所有schema：

   SELECT n.nspname AS schemaname, c.relname AS objectname, c.oid 
   FROM pg_class c
   JOIN pg_namespace n ON c.relnamespace = n.oid
   WHERE c.oid = 26223345;
   

修复措施 #

• 避免并发冲突：调整依赖对象的维护任务时间，确保和Lambda触发的处理流程错开；或者在处理流程执行前加锁（比如LOCK TABLE tablename IN ACCESS EXCLUSIVE MODE），阻止其他修改操作。
• 规范临时表使用：如果用临时表，确保在同一个Lambda会话内创建和使用，不要依赖外部会话的临时表；数据量不大的话，改用永久临时表（CREATE TEMP TABLE ... ON COMMIT PRESERVE ROWS）。
• 添加重试逻辑：在Lambda代码中针对could not open relation这类错误添加重试机制，间隔1-2分钟重试，避免因临时删除导致的单次失败。
• 监控对象变更：通过Redshift的stl_ddltext系统表监控关键对象的DDL操作，设置CloudWatch告警，一旦有删除/改名操作立即通知。
• 验证权限：确认Lambda使用的Redshift数据库用户或IAM角色拥有依赖对象的SELECT/USAGE权限，避免因权限问题导致的对象不可见。

内容的提问来源于stack exchange，提问作者john.new.1998