pgbouncer 作为连接池代理，其 “连接复用” 机制会打破应用逻辑会话与数据库物理连接的绑定关系，因此所有依赖 数据库会话（session）级状态 的操作都可能出现问题。除了 currval()，以下是常见的类似问题场景：
1. 会话级临时表（CREATE TEMPORARY TABLE）
问题：PostgreSQL 的临时表默认是 会话级 的（
ON COMMIT DELETE ROWS或ON COMMIT DROP），仅在当前数据库会话中可见。连接池影响：当应用释放连接后，临时表仍存在于被复用的物理连接中。若其他请求复用该连接，可能意外访问到不属于自己的临时表数据，或因表已存在导致
CREATE TEMPORARY TABLE报错。
示例：
-- 会话1创建临时表
CREATE TEMPORARY TABLE tmp_data (id int);
INSERT INTO tmp_data VALUES (1);
-- 会话1释放连接，连接被会话2复用
-- 会话2会意外看到 tmp_data 表及数据
SELECT * FROM tmp_data; -- 可能返回1，不符合预期
2. 会话级变量（SET LOCAL 或 SET SESSION）
问题：通过
SET命令设置的会话级参数（如SET search_path TO my_schema、SET timezone = 'UTC'），会影响当前连接的所有后续操作。连接池影响：若一个请求设置了会话变量后释放连接，其他请求复用该连接时会继承这些变量，导致参数不符合预期（例如访问错误的 schema、时区错乱）。
示例：
-- 会话1设置schema
SET search_path TO schema_a;
-- 会话1释放连接，会话2复用该连接
-- 会话2的查询会默认使用 schema_a，而非预期的默认schema
SELECT * FROM table; -- 实际查询 schema_a.table
3. 事务隔离级别的会话级设置
问题：通过
SET TRANSACTION ISOLATION LEVEL设置的事务隔离级别（如REPEATABLE READ），会作用于当前会话的所有后续事务。连接池影响：若前一个请求修改了隔离级别，后续复用连接的请求会继承该设置，可能导致事务行为不符合预期（如脏读、不可重复读）。
4. 会话级锁（SELECT ... FOR UPDATE 未释放）
问题：会话中未提交的事务若持有行锁或表锁，释放连接后，锁仍会保留在物理连接的事务中。
连接池影响：其他请求复用该连接时，可能因锁冲突导致操作阻塞，甚至死锁（尤其是
pgbouncer采用transaction或statement模式时，事务自动提交可能不及时）。
5. Prepared Statement（预编译语句）的会话绑定
问题：PostgreSQL 的预编译语句（
PREPARE）是会话级的，仅在创建它的会话中有效。连接池影响：若一个请求创建了预编译语句并释放连接，其他请求复用该连接时无法使用该语句（或因语句名冲突导致错误）。
6. lastval() 函数（与 currval() 类似）
问题：
lastval()返回当前会话中最后一次nextval()的结果，依赖会话级状态。连接池影响：与
currval()同理，连接复用会导致返回其他请求的nextval()结果，引发数据错误。
如何避免这些问题？
避免依赖会话级状态：
临时表改用全局表（加标识区分数据），或在事务结束后显式删除（
DROP TABLE tmp_data）。会话变量尽量在事务内用
SET LOCAL设置（仅作用于当前事务），而非SET SESSION。优先使用数据库级配置（如
ALTER DATABASE）而非会话级SET。
配置
pgbouncer为session模式：pgbouncer有三种模式：session（连接在整个会话期间独占）、transaction（事务结束后放回池）、statement（每条语句后放回池）。session模式能避免会话状态复用问题，但连接复用率低，性能较差，适合必须依赖会话状态的场景。
应用层主动清理会话状态：
在连接放回池前，执行
RESET ALL重置所有会话级参数，或DISCARD ALL清理临时表、预编译语句等（需谨慎，可能影响性能）。
总结
所有依赖 数据库会话级状态 的操作（临时表、会话变量、锁、预编译语句等），在 pgbouncer 等连接池下都可能因连接复用出现问题。核心解决方案是 减少对会话状态的依赖，或通过配置连接池模式兼容必要的会话绑定场景。