PgBouncer事务池模式与事务级advisory locks兼容性咨询

好问题！这确实是PgBouncer事务池模式下很容易混淆的点，咱们一步步拆开来理清楚：

核心结论 #

事务级Advisory Locks是可以和PgBouncer的transaction pool_mode正常配合使用的，问题出在大家常混淆的「会话级锁」和「事务级锁」的本质区别上。

1. 先搞懂两种锁的生命周期差异 #

• 会话级Advisory Locks（比如调用pg_advisory_lock()）：锁是绑定到数据库会话的，只要会话没断开、没主动释放，锁就一直攥在手里。但PgBouncer的事务池模式会在事务结束后立刻把连接放回池子，分给下一个请求——这就导致下一个请求会“继承”上一个会话残留的锁，完全乱套，所以这种锁绝对不能在事务池模式下用。
• 事务级Advisory Locks（比如调用pg_advisory_xact_lock()）：锁是绑定到当前事务的，事务一提交或回滚，锁会自动释放。这完美适配事务池的生命周期：每个请求的事务完成后，连接被回收，但锁已经跟着事务一起消失了，不会给下一个请求留下任何麻烦。

2. 为什么有“不要在PgBouncer里用Advisory Locks”的通用建议？ #

这个建议其实是特指会话级锁的，很多早期文档没把两种锁明确区分开，导致大家误以为所有advisory lock都不能碰。事务级锁完全不在这个禁忌列表里，只要你用对了函数，就没问题。

3. 关于Rails迁移的矛盾点怎么解释？ #

Rails迁移默认用会话级Advisory Locks来做互斥（防止多个节点同时跑迁移），而迁移本身默认包裹在事务里——但会话级锁不受事务影响，这就和PgBouncer事务池的连接复用逻辑冲突了，所以Rails 6才加了禁用迁移advisory lock的选项。

但这和你业务逻辑里用事务级锁的场景不冲突：

• 如果是在业务代码里用事务级锁，只要你的锁逻辑完全在事务块内调用pg_advisory_xact_lock()，就能正常工作。
• 如果要解决Rails迁移的问题，要么手动禁用迁移的advisory lock（自己保证迁移串行执行），要么给迁移单独配置一个用session模式的PgBouncer实例，或者针对特定迁移禁用事务后用其他互斥方式——这些都不影响业务代码里的事务级锁使用。

4. 实操时的注意事项 #

• 严格区分函数：一定要用带xact后缀的事务级锁函数，比如pg_advisory_xact_lock()、pg_advisory_xact_lock_shared()，别不小心用了会话级的pg_advisory_lock()。
• 锁逻辑要在事务内：事务级锁会在事务结束时自动释放，如果你在事务之外调用，锁会立刻释放，等于白加。
• 测试连接复用场景：模拟多个请求复用同一个数据库连接的情况，验证锁不会被意外保留或串用，确保逻辑符合预期。

内容的提问来源于stack exchange，提问作者karol.galanciak