应使用pg_advisory_xact_lock()实现用户级写入串行，因其事务级自动释放、开销小且不依赖额外表结构；误用非事务级pg_advisory_lock()会导致锁残留风险。
触发器本身不能直接限制并发写入
PostgreSQL 的 BEFORE INSERT/UPDATE 触发器在事务内执行，它看不到其他并发事务尚未提交的修改。所以单纯靠触发器查表判断“当前用户是否有未完成写入”，大概率会漏判——因为 SELECT 默认不加锁，读不到未提交行，也拦不住两个事务同时通过检查后写入。
真正起作用的是显式锁机制，触发器只是个“调度入口”。你需要让它配合 pg_advisory_xact_lock() 或行级锁来串行化操作。
用会话级咨询锁（advisory lock）实现用户级写入串行
这是最常用、开销小且不依赖额外表结构的做法。核心思路：每个用户 ID 映射一个咨询锁键，写入前申请排他锁，事务结束自动释放。
示例：限制对 orders 表的插入，按 user_id 串行：
CREATE OR REPLACE FUNCTION enforce_user_write_serial() RETURNS TRIGGER AS $$ BEGIN PERFORM pg_advisory_xact_lock(NEW.user_id::bigint); RETURN NEW; END; $$ LANGUAGE plpgsql; CREATE TRIGGER tr_enforce_user_write_serial BEFORE INSERT ON orders FOR EACH ROW EXECUTE FUNCTION enforce_user_write_serial();
-
pg_advisory_xact_lock()是事务级锁，自动释放，不用手动UNLOCK - 必须把
user_id转成bigint（咨询锁只接受int4或int8） - 如果
user_id可能为NULL，需提前RAISE EXCEPTION拒绝，否则锁键为 0，所有 NULL 用户会互斥 - 该锁跨连接有效，但仅对调用它的 SQL 生效；不阻塞
SELECT，只阻塞后续同样申请该键的pg_advisory_xact_lock()
用行级 SELECT ... FOR UPDATE 锁用户状态记录
适合已有用户元数据表（如 users），且你希望把“用户正在写入”状态持久化或审计。关键点是锁必须在触发器里完成，且目标行要存在、有索引。
假设 users 表有主键 id，且你确保所有 user_id 都已预置：
CREATE OR REPLACE FUNCTION enforce_user_write_with_row_lock() RETURNS TRIGGER AS $$ BEGIN PERFORM 1 FROM users WHERE id = NEW.user_id FOR UPDATE; RETURN NEW; END; $$ LANGUAGE plpgsql;
- 必须在
users的id列上有索引（主键即可），否则会锁整表 - 如果
NEW.user_id对应行不存在，PERFORM不报错也不锁任何东西，失去保护作用 - 相比咨询锁，它引入了额外 I/O 和可能的锁升级风险（比如热点用户行争用严重时）
- 锁持续到事务结束，期间其他事务对该用户行的任何
FOR UPDATE/FOR SHARE都会被阻塞
为什么不要用 pg_advisory_lock()（非事务级）？
常见错误是误用 pg_advisory_lock()（非 xact 版本），它不会随事务自动释放。一旦客户端异常断开或忘记 pg_advisory_unlock()，锁就永久残留，导致对应用户完全无法写入。
-
pg_advisory_lock()返回true后，锁一直持有直到显式调用pg_advisory_unlock()或连接关闭 - 连接池（如 pgbouncer）可能复用连接，进一步放大锁残留风险
- 没有超时机制，DBA 得手动查
pg_locks并KILL连接才能恢复 - 除非你有极强的连接生命周期控制能力，否则一律选
pg_advisory_xact_lock()
真正难的不是写触发器，而是确认锁粒度是否匹配业务语义——比如“单用户并发写入”是指同一 user_id 在同一张表？还是跨多张表？锁键设计和事务边界稍有偏差，就会漏锁或过度串行。
