PostgreSQL 12 RDS中临时表导致Lockmanager负载过高问题咨询

一、临时表为何会被加锁 #

虽然临时表的生命周期仅限于单个会话，但PostgreSQL依然会对其施加锁，核心原因有以下几点：

• 会话内多事务的协调需求：单个会话中可以存在多个事务（比如通过多次BEGIN/COMMIT开启的串行事务，或是借助dblink发起的并行事务），临时表在这些事务间是可见的。锁机制用来保证同会话内不同事务对临时表操作的一致性——比如一个事务正在修改临时表数据，另一个事务读取时需要获取共享锁，避免脏读。
• 元数据操作的锁约束：对临时表执行DDL操作（如ALTER TABLE、CREATE INDEX）时，需要获取排他锁，防止同会话内其他事务同时修改表结构，避免元数据不一致。PostgreSQL的锁框架是全局统一的，临时表的对象ID（OID）是全局唯一标识，锁管理器会基于OID处理所有对象的锁请求，不会为临时表单独豁免锁逻辑。
• 后台清理的锁依赖：当会话结束或临时表被删除时，PostgreSQL的后台进程需要清理临时表相关资源（如磁盘文件、元数据条目），这一过程需要获取锁来确保清理操作不会和会话内未完成的事务冲突。

二、ON COMMIT DROP能否降低锁负载 #

ON COMMIT DROP确实有助于降低锁管理器的负载，原因如下：

• 缩短锁的持有时间：使用ON COMMIT DROP创建的临时表会在事务提交时自动删除，锁的持有周期从整个会话缩短到单个事务。锁被快速释放，减少了锁管理器需要维护的锁条目数量。
• 减少元数据锁的长期占用：普通临时表的元数据会在会话结束后才被清理，期间对应的锁条目（即使是会话内的锁）会一直存在于锁管理器中。而ON COMMIT DROP的临时表在事务结束后立即销毁，元数据锁也随之释放，降低了锁管理器的资源占用。
• 避免会话内跨事务的锁竞争：如果会话内存在多个事务，普通临时表的锁会在事务间持续存在，可能引发会话内的锁等待。而ON COMMIT DROP的临时表每个事务结束就销毁，下一个事务需要时重新创建，不存在跨事务的锁持有，减少了锁竞争场景。

需要注意的是，如果你的场景中每个事务都需要重复创建相同结构的临时表，ON COMMIT DROP可能会增加DDL操作的开销，但对比锁管理器的负载压力，多数情况下这种开销是可接受的。

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