Informatica会话日志影响行数与Postgres目标表实际加载不符排查

• 事务未提交：如果会话配置了显式事务但未开启自动提交，或者Postgres的autocommit参数被设为off，处理的数据会停留在未提交的事务中，不会持久化到目标表。可以检查Informatica会话的事务属性配置，或者在Postgres中执行SELECT * FROM pg_stat_activity查看是否存在未提交的事务。
• 映射新增过滤/路由逻辑：可能后续修改映射时添加了隐藏的过滤器、表达式转换条件，或者调整了目标字段映射，导致数据被处理但未写入目标表。核对映射中的过滤规则、字段映射关系，以及转换组件的逻辑是否正确。
• 约束违例触发回滚：数据写入时触发了Postgres的约束限制（比如主键冲突、非空约束、字段类型不匹配），导致事务被回滚，但Informatica仅统计了源数据处理行数，未体现回滚情况。查看Postgres的日志文件（pg_log目录）或Informatica的会话日志，搜索rollback、constraint相关关键词定位问题。
• 目标表为临时表：若目标表是Postgres临时表，会话结束后临时表会自动销毁，自然看不到数据。执行SELECT relpersistence FROM pg_class WHERE relname = '目标表名';确认表类型，结果为p才是永久表。
• 统计计数逻辑偏差：Get Run Properties显示的受影响行数可能是源数据读取量，而非实际写入目标表的行数。查看会话详细日志，对比Source Qualifier的读取行数和Target的写入行数统计。
• Schema或权限问题：可能误连接到其他schema下的同名表，或者当前用户没有目标表的查询权限。执行SELECT current_schema();确认当前schema，再核对目标表所在schema是否正确，同时检查用户对目标表的权限。
• 数据被自动删除：目标表可能存在触发器，在数据写入后自动删除或转移数据；也可能有其他定时作业在会话执行后清理了数据。执行SELECT * FROM pg_trigger WHERE tgrelid = '目标表名'::regclass;查看触发器，或通过SELECT relmodtime FROM pg_class WHERE relname = '目标表名';检查表的修改时间是否异常。

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