PostgreSQL 临时表刚创建成功，下一条查询却报不存在

PostgreSQL 执行 CREATE TEMP TABLE ... ON COMMIT DROP AS SELECT ... 提示成功，下一条 SELECT 却报 relation does not exist。如果客户端逐条自动提交，临时表可能在创建语句提交时就已被删除，而不是 SELECT 找错了大小写。

ON COMMIT DROP 的含义是当前事务提交时删除这张临时表。它不会等待你下一次查询结束，也不等同于“断开连接后删除”。先核对建表语句和两次执行之间的实际事务边界。

建表成功与下一条还能访问，是两回事

下面这种顺序在每条语句各自提交的环境中会出问题：

CREATE TEMP TABLE report_items ON COMMIT DROP AS
SELECT 42 AS item_id;

SELECT * FROM report_items;

第一条语句可以成功建立表并写入示例行；但包裹它的事务随后提交，DROP 动作也随之发生。第二条语句开始时，该临时表已经不存在。

PostgreSQL 的每条 SQL 都在事务中执行。没有显式事务块且客户端也未建立跨语句事务时，单条成功语句会完成自己的提交。一些驱动或框架会自动开启事务，所以不能只凭界面上有两个执行按钮判断边界；应核对客户端的自动提交设置、驱动配置和实际 SQL 顺序。

另一个独立条件是连接。临时表属于创建它的数据库会话，另开查询窗口或把后续查询交给连接池中的另一条连接，不能依赖它仍然可见。若建表没有使用 ON COMMIT DROP，应优先查清是否切换了会话、是否发生回滚，以及名称是否一致，不要把所有找不到临时表的错误都归因于自动提交。

将创建与使用放进同一个受控事务

如果临时数据只服务一次工作单元，就让创建、使用、提交发生在同一连接的同一事务里。下面是独立测试会话中的完整示例，只建立一张含固定值的临时表：

BEGIN;

CREATE TEMP TABLE report_items ON COMMIT DROP AS
SELECT 42 AS item_id;

SELECT item_id FROM report_items;

COMMIT;

中间的 SELECT 应能读取示例值 42；提交后临时表应被删除。实际任务的查询要放在 COMMIT 之前。仅在建表前加 BEGIN，却在创建后立刻提交，仍然保不住后续查询所需的表。

示例应使用没有其他待提交业务改动的新测试连接，并选择未被使用的临时表名。不要把末尾 COMMIT 粘贴到正在处理未知业务写入的会话中，否则会提交那些已有修改。框架已经负责事务时，应使用它提供的事务范围管理，不在内部额外发送一套 BEGIN/COMMIT，也不要通过全局关闭自动提交影响其他请求。

若这个独立测试事务中途失败或决定取消，可回滚整个测试事务。回滚也会撤销这次事务中新建的临时表；不要期待回滚后还能继续读取它。真实业务事务失败时，依照该工作单元的回滚规则处理，不能为保留临时表而强行提交部分结果。

确实需要跨提交保留时，改变生命周期约定

如果应用需要在同一数据库会话的多个事务之间使用临时表，ON COMMIT DROP 就不符合这个需求。可以在新建表时明确选择默认的保留行为：

CREATE TEMP TABLE report_items ON COMMIT PRESERVE ROWS AS
SELECT 42 AS item_id;

这样提交不会自动删除表或清空数据，但会话结束仍会删除临时表。ON COMMIT DELETE ROWS 则会在提交时清空行、保留结构，与这两种行为都不同。

不要简单把 TEMP 去掉来延长寿命。那会建立持久表，改变可见范围、权限、命名冲突与清理责任。连接池中的同一物理会话又可能服务不同请求；选择 PRESERVE ROWS 时，必须安排作用范围和清理，不能把上一次请求留下的临时数据交给下一次请求。

如果任务跨会话或跨连接池事务借还连接，单纯改成 PRESERVE ROWS 仍不足以保证可用。应调整连接使用范围，或另行设计带请求身份、访问控制和清理规则的持久中间数据，而不是假定临时表全局共享。

验证创建、使用和结束三个时刻

修复后，在隔离会话中确认建表后、提交前能读取；提交后是否保留则必须符合选定的 ON COMMIT 行为。再让应用按真实的事务与连接借还方式完成一次测试，确认没有在使用前提前提交或切换连接。

这类修复通常涉及 SQL 和事务范围，不需要重启数据库或授予更多表权限。保留原查询及连接管理配置，回退时恢复本次变更；临时结果已经随提交或会话结束消失的，只能从允许重读的来源重新生成，不能靠再执行一次 SELECT 找回。涉及业务写入的工作单元不能为重建临时表而无条件整批重放。