PostgreSQL 换连接后 currval 报当前会话尚未定义

应用已经插入了记录，另开一个 SQL 窗口查询序列，却得到：

ERROR: currval of sequence "orders_id_seq" is not yet defined in this session

这不表示序列丢失，也不表示表中的 ID 没有保存。currval() 读取的是当前数据库会话曾取得的序列值，不是“全库最后插入的 ID”。重新连接后，这份会话状态不会从旧连接继承过来。

下文按 PostgreSQL 当前支持的序列规则处理普通自增主键插入。示例表为 public.orders，主键 id 已有正常工作的默认取号机制；不涉及修复导入后落后的序列或给应用补权限。

先确定要找的是哪一个 ID

如果要取得本次 INSERT 新建记录的 ID，应直接读取这条写入的返回结果。不要先在应用连接插入，再从管理工具的另一条连接运行 currval()。

即使用户名和数据库相同，两条连接仍然是不同会话。连接池也可能让两个相邻操作拿到不同的物理连接；应检查驱动和连接池的使用范围，而不是只对照登录用户名。

currval('public.orders_id_seq') 在当前会话通过该序列取得值后，可以稳定返回这份会话值，其他会话取号不会改变它。正常情况下，它来自本会话的 nextval()，包括默认值在插入时调用的取号；setval(..., true) 也能设置本会话的 currval，但这会改变共享序列，不能作为初始化读取状态的办法。

如果插入时显式提供了 ID，实际可能没有调用序列。此时即使查询与插入在同一连接，currval() 也不一定有定义；已有的会话值也可能属于更早的一次取号。

把 RETURNING 接在真正的插入语句上

以下只说明应用应采用的语句形状，需在允许写入的测试环境中，将表、列和示例值替换为实际参数绑定。不要为了取回一条已经插入的记录，再执行一次相同业务写入：

INSERT INTO public.orders (description)
VALUES ('example order')
RETURNING id;

应用从这次命令的结果集中读取 id，并按原有事务流程处理成功、提交或回滚。RETURNING 返回的是该语句插入的行，包括默认值生成的 ID，无须另外猜测序列名称或切换连接查询。

获得返回值不代表事务已经提交。若业务最终回滚，不能把该 ID 当成已经持久存在的订单继续对外确认。多行插入也会返回多行，应按驱动接口完整处理；不要在没有映射规则时，只取第一行或假定结果顺序就是输入顺序。

如果表根本没有默认生成机制，应先按既有表设计修复迁移定义，这与当前报错是不同问题。不要直接在业务表上复制一条 ALTER TABLE，更不要随意新建另一条同名相近的序列。

lastval、last_value 和 max(id) 都不是通用替代

lastval() 仍然是会话局部值，而且指向本会话最近使用的任意序列。触发器或其他插入可能调用另一条序列，因此把 currval() 换成 lastval() 不能解决跨连接读取，更不能保证取到目标表的 ID。

读取序列关系的 last_value 是观察共享序列状态。并发取号、缓存和未提交操作使它不能可靠对应“我的插入”。SELECT max(id) 同样只是在查询当时看见的表数据中取最大值，不是本次操作的返回凭据。

为让错误消失而先调用一次 nextval() 会实际消耗新编号；这个号码未必对应任何订单。setval() 更会修改全局状态，可能影响其他写入。两者都不是无副作用的检查，不能在生产环境反复试号。

验证连接与返回结果，不要求编号连续

在隔离环境通过应用正常入口插入两条可区分的测试记录，核对每次 RETURNING 的 ID 与对应业务内容。再分别检查连接池借还、重新连接和事务失败路径，确认程序不再依赖另一个会话的序列读取状态。

保留旧查询代码与事务配置，修复通常只需调整应用取得 ID 的方式。已经成功的业务写入应通过保存的业务唯一标识或原返回结果查询，不能盲目重发；若没有可靠关联条件，先处理定位问题。

序列取号在事务回滚后通常不会被收回，出现空号不属于这次修复失败。回退代码也不应把序列往回调，更不能删除有效订单来填补编号间隙。