PostgreSQL中DROP/CREATE触发器与函数的原子性、事务支持及锁风险咨询

一、原子性 #

PostgreSQL中针对触发器和函数的CREATE/DROP操作本身具备原子性：

• 执行CREATE FUNCTION/CREATE TRIGGER时，只有当所有依赖条件满足、语法完全正确时，对象才会被完整创建；一旦过程中出现错误（比如依赖表不存在、语法报错），操作会完全回滚，不会留下不完整的函数或触发器。
• DROP FUNCTION/DROP TRIGGER操作同样是原子的，要么目标对象被彻底删除，要么操作失败，不会出现对象部分删除的中间状态。

二、事务支持 #

从PostgreSQL 11版本开始，触发器和函数的CREATE/DROP操作完全支持事务包裹：

• 你可以将多个相关DDL操作放在同一个事务中，比如先创建函数再基于该函数创建触发器。如果事务中任意一步失败，整个事务会回滚，所有DDL操作的结果都会被撤销，不会出现“函数创建成功但触发器创建失败”的不一致状态。
• 注意：极少数特殊DDL（如DROP DATABASE）仍不支持事务，但触发器和函数的相关操作不在此列。

三、锁风险 #

函数的CREATE/DROP操作 #

• 操作时仅会对函数对象本身加ACCESS EXCLUSIVE锁，不会锁定关联的表。这个锁只会阻塞其他针对该函数的DDL操作（比如修改、删除该函数），不会影响表的读写。
• 如果有正在执行的业务查询正在调用目标函数，DROP FUNCTION会等待这些查询执行完毕后才能继续；反之，若DROP FUNCTION先持有锁，后续调用该函数的查询会被阻塞直到锁释放。

触发器的CREATE/DROP操作 #

• 操作时需要对目标表加SHARE ROW EXCLUSIVE锁：
  • 这个锁会阻塞表的所有写操作（INSERT/UPDATE/DELETE），但允许读操作（SELECT）正常执行。
  • 在高活跃表上执行这类操作时，如果表上有大量未完成的写事务，触发器的CREATE/DROP会被阻塞；同时，该操作持有的锁也会阻塞后续的写请求，可能导致业务延迟甚至锁等待超时。
• 建议在业务低峰期执行触发器的CREATE/DROP操作，尽量缩短操作的执行时间，避免长时间持有锁影响业务。

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