本節簡單介紹了PostgreSQL手工執行vacuum的處理流程,主要分析了ExecVacuum->vacuum->vacuum_rel->heap_vacuum_rel->lazy_scan_heap->HeapTupleSatisfiesVacuum函式的實現邏輯,該函式判斷一個元組是否可對所有正在執行中的事務可見。

### 一、資料結構
**宏定義**
Vacuum和Analyze命令選項
```
/* ----------------------
 *      Vacuum and Analyze Statements
 *      Vacuum和Analyze命令選項
 * 
 * Even though these are nominally two statements, it's convenient to use
 * just one node type for both.  Note that at least one of VACOPT_VACUUM
 * and VACOPT_ANALYZE must be set in options.
 * 雖然在這裡有兩種不同的語句,但只需要使用統一的Node型別即可.
 * 注意至少VACOPT_VACUUM/VACOPT_ANALYZE在選項中設定.
 * ----------------------
 */
typedef enum VacuumOption
{
    VACOPT_VACUUM = 1 << 0,     /* do VACUUM */
    VACOPT_ANALYZE = 1 << 1,    /* do ANALYZE */
    VACOPT_VERBOSE = 1 << 2,    /* print progress info */
    VACOPT_FREEZE = 1 << 3,     /* FREEZE option */
    VACOPT_FULL = 1 << 4,       /* FULL (non-concurrent) vacuum */
    VACOPT_SKIP_LOCKED = 1 << 5,    /* skip if cannot get lock */
    VACOPT_SKIPTOAST = 1 << 6,  /* don't process the TOAST table, if any */
    VACOPT_DISABLE_PAGE_SKIPPING = 1 << 7   /* don't skip any pages */
} VacuumOption;

```

### 二、原始碼解讀
**HeapTupleSatisfiesVacuum**
HeapTupleSatisfiesVacuum為VACUUM操作確定元組的狀態.在這裡,我們主要想知道的是一個元組是否可對所有正在執行中的事務可見.如可見,則不能透過VACUUM刪除該元組.

主要處理流程如下:
0.獲取tuple並執行相關校驗
1.條件:插入事務未提交
1.1條件:無效的xmin,該元組已廢棄可刪除
1.2條件:舊版本(9.0-)的判斷
1.3條件:xmin為當前事務ID
1.4條件:插入事務非當前事務,正在進行中
1.5條件:xmin事務確實已提交(透過clog判斷)
1.6條件:其他情況
-- 至此,可以確定xmin已提交
2.條件:xmax是無效的事務ID,直接返回LIVE
3.條件:xmax只是鎖定
3.1條件:xmax事務未提交,分多事務&非多事務進行判斷
3.2條件:只是鎖定,返回LIVE
4.條件:存在子事務
4.1條件:xmax正在進行,返回事務進行中
4.2條件:xmax已提交,區分xmax在OldestXmin之前還是之後
4.3條件:xmax不在執行中/沒有提交/沒有回滾或崩潰,則設定xmax為無效事務ID
4.4預設返回LIVE
5.條件:xmax沒有提交
5.1條件:刪除過程中
5.2條件:透過clog判斷,該事務已提交,設定事務標記位
5.3條件:其他情況,設定為無效事務ID
5.4預設返回LIVE
-- 至此,可以確定xmax已提交
6.元組xmax≥OldestXmin,最近刪除
7.預設元組已DEAD

```
/*
 * HeapTupleSatisfiesVacuum
 *
 *  Determine the status of tuples for VACUUM purposes.  Here, what
 *  we mainly want to know is if a tuple is potentially visible to *any*
 *  running transaction.  If so, it can't be removed yet by VACUUM.
 *  為VACUUM確定元組的狀態.
 *  在這裡,我們主要想知道的是一個元組是否可對所有正在執行中的事務可見.
 *  如可見,則不能透過VACUUM刪除該元組.
 *
 * OldestXmin is a cutoff XID (obtained from GetOldestXmin()).  Tuples
 * deleted by XIDs >= OldestXmin are deemed "recently dead"; they might
 * still be visible to some open transaction, so we can't remove them,
 * even if we see that the deleting transaction has committed.
 * OldestXmin是一個cutoff XID(透過GetOldestXmin函式獲得).
 * 透過XIDs >= OldestXmin刪除的元組被視為"最近死亡",它們可能仍然對某些正在進行中的事務可見,
 *   因此就算刪除事務已提交,我們仍然不能清除它們.
 */
HTSV_Result
HeapTupleSatisfiesVacuum(HeapTuple htup, TransactionId OldestXmin,
                         Buffer buffer)
{
    //獲取tuple
    HeapTupleHeader tuple = htup->t_data;
    //校驗
    Assert(ItemPointerIsValid(&htup->t_self));
    Assert(htup->t_tableOid != InvalidOid);

/*
     * Has inserting transaction committed?
     * 插入事務已提交?
     *
     * If the inserting transaction aborted, then the tuple was never visible
     * to any other transaction, so we can delete it immediately.
     * 如果插入事務已回滾,元組對其他事務均不可見,因此可以馬上刪除.
     */
    if (!HeapTupleHeaderXminCommitted(tuple))
    {
        //1.插入事務未提交
        if (HeapTupleHeaderXminInvalid(tuple))
            //1-1.無效的xmin,該元組已廢棄可刪除
            return HEAPTUPLE_DEAD;
        /* Used by pre-9.0 binary upgrades */
        //用於9.0以前版本的升級,HEAP_MOVED_OFF&HEAP_MOVED_IN已不再使用
        else if (tuple->t_infomask & HEAP_MOVED_OFF)
        {
            TransactionId xvac = HeapTupleHeaderGetXvac(tuple);

if (TransactionIdIsCurrentTransactionId(xvac))
                return HEAPTUPLE_DELETE_IN_PROGRESS;
            if (TransactionIdIsInProgress(xvac))
                return HEAPTUPLE_DELETE_IN_PROGRESS;
            if (TransactionIdDidCommit(xvac))
            {
                SetHintBits(tuple, buffer, HEAP_XMIN_INVALID,
                            InvalidTransactionId);
                return HEAPTUPLE_DEAD;
            }
            SetHintBits(tuple, buffer, HEAP_XMIN_COMMITTED,
                        InvalidTransactionId);
        }
        /* Used by pre-9.0 binary upgrades */
        //用於9.0以前版本的升級
        else if (tuple->t_infomask & HEAP_MOVED_IN)
        {
            TransactionId xvac = HeapTupleHeaderGetXvac(tuple);

if (TransactionIdIsCurrentTransactionId(xvac))
                return HEAPTUPLE_INSERT_IN_PROGRESS;
            if (TransactionIdIsInProgress(xvac))
                return HEAPTUPLE_INSERT_IN_PROGRESS;
            if (TransactionIdDidCommit(xvac))
                SetHintBits(tuple, buffer, HEAP_XMIN_COMMITTED,
                            InvalidTransactionId);
            else
            {
                SetHintBits(tuple, buffer, HEAP_XMIN_INVALID,
                            InvalidTransactionId);
                return HEAPTUPLE_DEAD;
            }
        }
        else if (TransactionIdIsCurrentTransactionId(HeapTupleHeaderGetRawXmin(tuple)))
        {
            //1-3.xmin為當前事務ID
            if (tuple->t_infomask & HEAP_XMAX_INVALID)  /* xid invalid */
                //1-3-1.xmax無效,說明插入事務正在進行中
                return HEAPTUPLE_INSERT_IN_PROGRESS;
            /* only locked? run infomask-only check first, for performance */
            //只是鎖定?效能考慮,首先執行infomask-only檢查
            if (HEAP_XMAX_IS_LOCKED_ONLY(tuple->t_infomask) ||
                HeapTupleHeaderIsOnlyLocked(tuple))
                //1-3-2.鎖定狀態(如for update之類),事務正在進行中
                return HEAPTUPLE_INSERT_IN_PROGRESS;
            /* inserted and then deleted by same xact */
            //插入,然後刪除
            if (TransactionIdIsCurrentTransactionId(HeapTupleHeaderGetUpdateXid(tuple)))
                //1-3-3.插入,然後刪除
                return HEAPTUPLE_DELETE_IN_PROGRESS;
            /* deleting subtransaction must have aborted */
            //預設:插入事務正在進行中
            return HEAPTUPLE_INSERT_IN_PROGRESS;
        }
        else if (TransactionIdIsInProgress(HeapTupleHeaderGetRawXmin(tuple)))
        {
            //1-4.插入事務非當前事務,正在進行中
            /*
             * It'd be possible to discern between INSERT/DELETE in progress
             * here by looking at xmax - but that doesn't seem beneficial for
             * the majority of callers and even detrimental for some. We'd
             * rather have callers look at/wait for xmin than xmax. It's
             * always correct to return INSERT_IN_PROGRESS because that's
             * what's happening from the view of other backends.
             * 透過檢視xmax，可以區分正在進行的插入/刪除操作 - 但這對於大多數呼叫者並沒有好處,甚至有害
             * 我們寧願讓呼叫者檢視/等待xmin而不是xmax。
             * 返回INSERT_IN_PROGRESS總是正確的，因為這是從其他後臺程式檢視中看到正在發生的。
             */
            return HEAPTUPLE_INSERT_IN_PROGRESS;
        }
        else if (TransactionIdDidCommit(HeapTupleHeaderGetRawXmin(tuple)))
            //1-5.xmin事務確實已提交(透過clog判斷)
            SetHintBits(tuple, buffer, HEAP_XMIN_COMMITTED,
                        HeapTupleHeaderGetRawXmin(tuple));
        else
        {
            //1-5.其他情況
            //既不在進行中,也沒有提交,要麼是回滾,要麼是崩潰了
            /*
             * Not in Progress, Not Committed, so either Aborted or crashed
             */
            //設定標記位
            SetHintBits(tuple, buffer, HEAP_XMIN_INVALID,
                        InvalidTransactionId);
            //返回廢棄標記
            return HEAPTUPLE_DEAD;
        }

/*
         * At this point the xmin is known committed, but we might not have
         * been able to set the hint bit yet; so we can no longer Assert that
         * it's set.
         * 在這個點上,xmin事務確認已提交,但這時候還是不能設定hint bit,
         *   因此不能斷定已設定標記.
         */
    }

/*
     * Okay, the inserter committed, so it was good at some point.  Now what
     * about the deleting transaction?
     * 插入資料的事務已提交,現在可以看看刪除事務的狀態了.
     */
    if (tuple->t_infomask & HEAP_XMAX_INVALID)
        //------- 2.xmax是無效的事務ID,直接返回LIVE
        return HEAPTUPLE_LIVE;

if (HEAP_XMAX_IS_LOCKED_ONLY(tuple->t_infomask))
    {
        //------- 3.鎖定
        /*
         * "Deleting" xact really only locked it, so the tuple is live in any
         * case.  However, we should make sure that either XMAX_COMMITTED or
         * XMAX_INVALID gets set once the xact is gone, to reduce the costs of
         * examining the tuple for future xacts.
         * "Deleting"事務確實只是鎖定該元組,因此該元組是存活狀態.
         * 但是,我們應該確保不管是XMAX_COMMITTED還是XMAX_INVALID標記,應該在事務完結後馬上設定,
         *   這樣可以減少為了事務檢查元組狀態的成本.
         */
        if (!(tuple->t_infomask & HEAP_XMAX_COMMITTED))
        {
            //3.1 xmax事務未提交
            if (tuple->t_infomask & HEAP_XMAX_IS_MULTI)
            {
                //3.1.1 多事務
                /*
                 * If it's a pre-pg_upgrade tuple, the multixact cannot
                 * possibly be running; otherwise have to check.
                 * 如果是pre-pg_upgrade元組,多事務不可能執行,否則的話,只能執行檢查
                 */
                if (!HEAP_LOCKED_UPGRADED(tuple->t_infomask) &&
                    MultiXactIdIsRunning(HeapTupleHeaderGetRawXmax(tuple),
                                         true))
                    return HEAPTUPLE_LIVE;
                //其他情況,根據clog重新設定事務狀態標記位
                SetHintBits(tuple, buffer, HEAP_XMAX_INVALID, InvalidTransactionId);
            }
            else
            {
                //3.1.2 非多事務
                if (TransactionIdIsInProgress(HeapTupleHeaderGetRawXmax(tuple)))
                    //xmax事務正在進行,返回LIVE
                    return HEAPTUPLE_LIVE;
                //否則,根據clog重新設定事務狀態標記位
                SetHintBits(tuple, buffer, HEAP_XMAX_INVALID,
                            InvalidTransactionId);
            }
        }

/*
         * We don't really care whether xmax did commit, abort or crash. We
         * know that xmax did lock the tuple, but it did not and will never
         * actually update it.
         * 我們確實不需要真正關心xmax是否提交/回滾/崩潰.
         * 我們知道xmax事務鎖定了元組,但沒有而且"從未"更新過該元組.
         */
        //3.2 只是鎖定,返回LIVE
        return HEAPTUPLE_LIVE;
    }

if (tuple->t_infomask & HEAP_XMAX_IS_MULTI)
    {
        //4.存在子事務
        //獲取刪除事務號xmax
        TransactionId xmax = HeapTupleGetUpdateXid(tuple);

/* already checked above */
        Assert(!HEAP_XMAX_IS_LOCKED_ONLY(tuple->t_infomask));

/* not LOCKED_ONLY, so it has to have an xmax */
        //根據上述xmax的判斷,到這裡可以肯定xmax是有效的
        Assert(TransactionIdIsValid(xmax));

if (TransactionIdIsInProgress(xmax))
            //4.1 xmax正在進行,返回進行中
            return HEAPTUPLE_DELETE_IN_PROGRESS;
        else if (TransactionIdDidCommit(xmax))
        {
            //4.2 xmax已提交
            /*
             * The multixact might still be running due to lockers.  If the
             * updater is below the xid horizon, we have to return DEAD
             * regardless -- otherwise we could end up with a tuple where the
             * updater has to be removed due to the horizon, but is not pruned
             * away.  It's not a problem to prune that tuple, because any
             * remaining lockers will also be present in newer tuple versions.
             */
            if (!TransactionIdPrecedes(xmax, OldestXmin))
                //4.2.1 xmax在OldestXmin之後,
                //表示在OldestXmin之後才刪除,返回HEAPTUPLE_RECENTLY_DEAD
                return HEAPTUPLE_RECENTLY_DEAD;
            //4.2.2 xmax在OldestXmin之前,返回DEAD
            return HEAPTUPLE_DEAD;
        }
        else if (!MultiXactIdIsRunning(HeapTupleHeaderGetRawXmax(tuple), false))
        {
            /*
             * Not in Progress, Not Committed, so either Aborted or crashed.
             * Mark the Xmax as invalid.
             */
            //4.3 xmax不在執行中/沒有提交/沒有回滾或崩潰,則設定xmax為無效事務ID
            SetHintBits(tuple, buffer, HEAP_XMAX_INVALID, InvalidTransactionId);
        }

//4.4 預設返回LIVE
        return HEAPTUPLE_LIVE;
    }

if (!(tuple->t_infomask & HEAP_XMAX_COMMITTED))
    {
        //5.xmax沒有提交
        if (TransactionIdIsInProgress(HeapTupleHeaderGetRawXmax(tuple)))
            //5.1 刪除過程中
            return HEAPTUPLE_DELETE_IN_PROGRESS;
        else if (TransactionIdDidCommit(HeapTupleHeaderGetRawXmax(tuple)))
            //5.2 透過clog判斷,該事務已提交,設定事務標記位
            SetHintBits(tuple, buffer, HEAP_XMAX_COMMITTED,
                        HeapTupleHeaderGetRawXmax(tuple));
        else
        {
            /*
             * Not in Progress, Not Committed, so either Aborted or crashed
             */
            //5.3 其他情況,設定為無效事務ID
            SetHintBits(tuple, buffer, HEAP_XMAX_INVALID,
                        InvalidTransactionId);
            //返回LIVE
            return HEAPTUPLE_LIVE;
        }

/*
         * At this point the xmax is known committed, but we might not have
         * been able to set the hint bit yet; so we can no longer Assert that
         * it's set.
         */
        //至此,xmax可以確認已提交
    }

/*
     * Deleter committed, but perhaps it was recent enough that some open
     * transactions could still see the tuple.
     */
    if (!TransactionIdPrecedes(HeapTupleHeaderGetRawXmax(tuple), OldestXmin))
        //6.元組xmax≥OldestXmin,最近刪除
        return HEAPTUPLE_RECENTLY_DEAD;

/* Otherwise, it's dead and removable */
    //7. 預設元組已DEAD
    return HEAPTUPLE_DEAD;
}

```

### 三、跟蹤分析
參見[PostgreSQL 原始碼解讀（118）- MVCC#3(Tuple可見性判斷)](http://blog.itpub.net/6906/viewspace-2558348/)

### 四、參考資料
[PG Source Code](https://doxygen.postgresql.org)
[PostgreSQL 原始碼解讀（118）- MVCC#3(Tuple可見性判斷)](http://blog.itpub.net/6906/viewspace-2558348/)
[PostgreSQL 原始碼解讀（130）- MVCC#14（vacuum過程-lazy_scan_heap函式）](http://blog.itpub.net/6906/viewspace-2565086/)

PostgreSQL 原始碼解讀（134）- MVCC#18（vacuum過程-HeapTupleSatisfiesVacuum函式）

相關文章