postgresql四种逻辑复制的状态

准备

CreateCheckpoint，或者bgwriter启动时，或者创建logicalreplicationslot时都会调用LogStandbySnapshot 记录一个XLOG_RUNNING_XACTS类型的日志。日志中记录了所有提交的事务的xid(HistoricSnapshot)

启动（SNAPBUILD_BUILDING_SNAPSHOT）

当接收端读到 XLOG_RUNNING_XACTS 时，调用SnapBuildProcessRunningXacts开始记录所有看到的日志，但此时只知道提交的事务，不知道进行中的事务。在没有完整事务状态的情况下，接收端是不能开始apply日志的。这时日志中记录的 nextxid(1) 就是这之后再开启事务时的最小事务号。

组装事务状态（SNAPBUILD_FULL_SNAPSHOT）

当接收端再收到 XLOG_RUNNING_XACTS 时，如果发现nextxid(1)之前的日志都提交了，就证明当前从日志收集过的事务，已经是全部在运行的事务了，没有不知道的事务，此时事务状态是完整的，但因为之前收到的非事务的 log 都人为丢弃了，不能对这些事务 apply log，因为事务不完整，这时nextxid(２)记录的就是之后再开启事务的时的最小事务号 。

这时每次 apply 前要判断，要 apply 的这个事务的xid是否在nextxid(２)之前，如果是之前的就不apply，之后的才apply（SnapBuildProcessChange）。

第一次apply的时候会记录一个完整的HistoricSnapshot作为basesnapshot

事务状态已完整（SNAPBUILD_CONSISTENT）

当接收端再收到 XLOG_RUNNING_XACTS 时，如果发现nextxid(２)之前的日志都提交了，说明以后收到的 log一定可以 apply，不用再做上面的判断了。

第一次到这个状态时会写一个.snap文件

新的事务提交日志(SnapBuildCommitTxn)

在每次处理事务提交日志时，它会感知所有修改系统表的事务，把它们加入新snapshot中（SnapBuildAddCommittedTxn），并把这个新的 snapshot 挂到所有事务的reorderbuffer中（SnapBuildDistributeNewCatalogSnapshot）。当其它事务commit时（DecodeCommit），检查reorder_buffer（ReorderBufferCommit），就会 apply 这个 snapshot （TeardownHistoricSnapshot + SetupHistoricSnapshot）