1、外掛初始化設定callback函式commit_cb

它處理事務提交資訊，但這裡拿不到太多，LogicalDecodingContext 中並沒有包含事務狀態。

2、邏輯解碼

src/backend/replication/logical/logical.c

callback函式 commit_cb 封裝在 commit_cb_wrapper 中，設定到下一層的callback中：

/* commit callback signature */
typedef void (*ReorderBufferCommitCB) (
									   ReorderBuffer *rb,
									   ReorderBufferTXN *txn,
									   XLogRecPtr commit_lsn);
 

定義就不多說了，我們的目標是找到事務是否有控制標誌，設定流程是什麼，程式碼細節有興趣自己看吧。

3、解碼

再繼續看下去，解碼事務提交的函式是：DecodeCommit。

src/backend/replication/logical/decode.c

這裡可以看到，對於回滾掉的事務，也有一個專門的處理函式：DecodeAbort，它直接釋放已經解碼的結構。

4、事務標誌位

  if (parsed->xinfo & XACT_XINFO_HAS_ORIGIN)
  {
    origin_lsn = parsed->origin_lsn;
    commit_time = parsed->origin_timestamp;
  }
 

隨著程式碼的深入，它終於出現。擴充套件標誌位xinfo，說擴充套件是由名字猜測。

/* does this record have a 'xinfo' field or not */
#define XLOG_XACT_HAS_INFO			0x80

而有沒有xinfo由這個標誌來確認，更多資訊可以根據程式碼或者註釋來了解。

5、它是什麼時候設定的

src/backend/access/transam/xact.c 函式 XactLogCommitRecord

事務提交時根據狀態寫入。

6、我們還能看出什麼

根據過濾器跳過部分事務

  if (SnapBuildXactNeedsSkip(ctx->snapshot_builder, buf->origptr) ||
    (parsed->dbId != InvalidOid && parsed->dbId != ctx->slot->data.database) ||
    ctx->fast_forward || FilterByOrigin(ctx, origin_id))
  {
    for (i = 0; i < parsed->nsubxacts; i++)
    {
      ReorderBufferForget(ctx->reorder, parsed->subxacts[i], buf->origptr);
    }
    ReorderBufferForget(ctx->reorder, xid, buf->origptr);

    return;
  }
 

那麼，如果我們想自行控制事務是否解碼，就可以使用這段邏輯，絲毫不用擔心。

7、還有更多

繼續上一點，不管事務是不是需要複製，都是要解碼的，根據過濾條件再釋放，也就是有一些無意義的開銷。

其實這個過程還有很多不相關程式碼的閱讀，確定無關就忽略掉，這裡只列出有影響的部分。

沒有開發文件，只能依靠程式碼和註釋的解讀。有更好的方法、經驗、建議