PostgreSQL逻辑复制：不同事务能否共享同一LSN？场景与排序问题

在处理PostgreSQL publication输出的逻辑复制变更时，由于外部限制无法假设变更按时间顺序排列（变更被存入无序队列），计划依赖LSN的单调性进行排序，需要明确以下问题：

1. 来自不同事务的逻辑复制变更能否共享同一LSN？若可以，会在哪些场景下发生？
2. 多事务共享同一LSN的概率有多大？
3. 逻辑变更携带的“PostgreSQL毫秒级提交时间戳”能否可靠打破LSN相同时的排序僵局？

示例场景 #

正常情况下，LSN单调递增，可通过LSN判断变更顺序：

LSN: 03
type: create
data: {
  pk_id: 123,
  column_1: foo
}

---

LSN: 02
type: delete
data: {
  pk_id: 123,
  column_1: bar
}

可得出记录123先被删除、后被创建的结论。但是否会出现跨事务变更共享同一LSN的情况？例如：

LSN: 02
type: create
data: {
  pk_id: 123,
  column_1: foo
}
---
LSN: 02
type: delete
data: {
  pk_id: 123,
  column_1: bar
}

核心结论 #

不同事务的逻辑复制变更确实可能共享同一LSN，这是PostgreSQL WAL写入机制导致的实际场景，而非理论假设。

一、共享LSN的典型场景 #

LSN本质是WAL（预写日志）的位置标识，而非事务的唯一ID。当多个事务的WAL记录被打包写入同一WAL页面或连续区间时，就会出现跨事务共享LSN的情况，具体场景包括：

• 批量短事务提交：大量仅含单条DML的短事务在极短时间内连续提交，PostgreSQL会将它们的WAL记录合并写入同一LSN区间，最终逻辑复制输出时标记为同一LSN。
• WAL页面填充优化：WAL以固定大小页面（默认16KB）为单位写入，若多个小事务的WAL记录总大小未填满一个页面，会被打包到同一页面，复用起始LSN。
• 高并发快速提交：高负载下多个并行事务几乎同时完成提交，WAL写入操作被调度到同一LSN位置。

二、LSN共享的概率 #

概率完全取决于系统负载特征：

• 长事务、大事务为主的系统中，概率极低——单个事务的WAL记录会占用大量空间，很难与其他事务共享LSN。
• OLTP高频短事务场景中，概率显著提升，尤其是事务提交间隔小于WAL写入调度粒度时。

三、提交时间戳的可靠性 #

毫秒级提交时间戳可作为LSN相同时的排序补充，但存在局限性：

• 精度限制：同一毫秒内提交的事务会有相同时间戳，仍无法区分顺序。
• 时钟依赖：依赖数据库服务器系统时钟，极端场景下的时钟回拨会破坏时间戳单调性。
• 事务内重复：同一事务内的所有变更时间戳相同，不影响单事务排序，但跨事务的相同时间戳仍有歧义。

四、依赖LSN排序的权衡与优化策略 #

若依赖LSN排序，需注意以下要点：

1. LSN的单调性边界：PostgreSQL仅保证单个事务内的变更LSN单调递增，跨事务的LSN可能重复，此时无法仅通过LSN判断顺序。
2. 复合排序键方案：建议采用 LSN + 提交时间戳 + 事务ID（XID） 的复合排序逻辑：
   • 优先用LSN保证整体WAL写入顺序；
   • LSN相同时，用提交时间戳细化排序；
   • 时间戳也相同时，用全局单调递增的XID作为最终依据，唯一区分事务先后。
3. 无序队列处理：消费变更时必须严格按复合排序键排序后再处理，否则可能出现数据不一致（如先处理创建再处理删除，导致无效记录残留）。

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