openGauss/MogDB列存表vacuum DELTAMERGE過程申請的鎖

之前測試openGauss列存表vacuum DELTAMERGE的時候，發現pg_delta表會在做完vacuum DELTAMERGE後，使用新的物理檔案，pg_delta表的relfilenode會發生變化，相當於表重建了。
同時為了測試vacuum DELTAMERGE過程申請了什麼鎖，大致瞅了眼原始碼，從原始碼裡看vacuum DELTAMERGE過程申請了AccessExclusiveLock鎖。

如下是對鎖的驗證：

因為測試環境配置有限，做vacuum DELTAMERGE較快，比較難抓到鎖。所以我想到了直接從鎖入手，AccessExclusiveLock是8級鎖，主庫申請8級鎖時，會將其記錄到WAL日誌裡。
所以，在測試之前。我先切了一個日誌。

openGauss=# select pg_switch_xlog();
 pg_switch_xlog
----------------
 0/3003058
(1 row)

這樣在我使用mog_xlogdump解析新的日誌裡的時候，儘量不讓其他的wal記錄干擾我。

omm1@ubuntu-linux-22-04-desktop:/opt/opengauss/data/pg_xlog$ mog_xlogdump  -R int,varchar,timestamp 000000010000000000000004 | grep -i AccessExclusive
mog_xlogdump: FATAL:  error in WAL record at 0/4002B78: invalid record length at 0/40030D0: wanted 32, got 0

然後獲取現在的txid=15156，這樣下一次我做操作的txid是15157

openGauss=# select txid_current();
 txid_current
--------------
        15156
(1 row)
openGauss=# vacuum DELTAMERGE test_cstore;
DELTA MERGE

做完操作後，再用mog_xlogdump解析wal日誌，
發現多了三條AccessExclusive Lock的相關記錄，xid和預期的15157項對應，三條記錄均與做的操作有關。

omm1@ubuntu-linux-22-04-desktop:/opt/opengauss/data/pg_xlog$ mog_xlogdump  -R int,varchar,timestamp 000000010000000000000004 | grep -i AccessExclusive
mog_xlogdump: FATAL:  REDO @ 0/40001D0; LSN 0/4000210: prev 0/4000188; xid 15157; term 1; len 24; total 58; crc 3716495508; desc: Standby - AccessExclusive locks: nlocks 1  xid 15157 db 14595 rel 24576
REDO @ 0/4000700; LSN 0/4000740: prev 0/40005D0; xid 15157; term 1; len 24; total 58; crc 2397906544; desc: Standby - AccessExclusive locks: nlocks 1  xid 15157 db 14595 rel 24580
REDO @ 0/4002150; LSN 0/4002190: prev 0/40020F8; xid 15157; term 1; len 24; total 58; crc 145047305; desc: Standby - AccessExclusive locks: nlocks 1  xid 15157 db 14595 rel 24657
error in WAL record at 0/4003150: invalid record length at 0/40031F0: wanted 32, got 0

openGauss=# select oid,relfilenode,relname from pg_class where relfilenode=24576 or relfilenode=24580 or relfilenode=24657;
  oid  | relfilenode |    relname
-------+-------------+----------------
 24576 |       24576 | test_cstore
 24580 |       24657 | pg_delta_24576
(2 rows)

根據上述列印的三個relfilenode在資料庫裡查詢，可以發現，vacuum DELTAMERGE過程，列存表原表，delta表均獲取了8級鎖，AccessExclusive Lock，除此之外，還有一個relfilenode對應的表，其實是delta表的原表，在vacuum DELTAMERGE過程中，delta表發生了重建，對應的表檔案發生了變化。

這一現象和上文測試中：原始的pg_delta表會在做完vacuum DELTAMERGE後，拋棄原來的物理檔案，直接使用新的物理檔案，pg_delta表的relfilenode會發生變化的現象一致。

除此之外也可以在一個執行緒做vacuum DELTAMERGE的同時，使用perf命令記錄呼叫棧，並生成svg火焰圖，可以看到vacuum DELTAMERGE過程申請了AccessExclusiveLock，需要用LogAccessExclusiveLock()呼叫LogAccessExclusiveLocks()把鎖記錄寫到xlog裡。

/*
 * Wholesale logging of AccessExclusiveLocks. Other lock types need not be
 * logged, as described in backend/storage/lmgr/README.
 */
static void LogAccessExclusiveLocks(int nlocks, xl_standby_lock* locks)
{
    xl_standby_locks xlrec;
    xlrec.nlocks = nlocks;
    XLogBeginInsert();
    XLogRegisterData((char*)&xlrec, MinSizeOfXactStandbyLocks);
    XLogRegisterData((char*)locks, nlocks * sizeof(xl_standby_lock));
    (void)XLogInsert(RM_STANDBY_ID, XLOG_STANDBY_LOCK);
}
/*
 * Individual logging of AccessExclusiveLocks for use during LockAcquire()
 */
void LogAccessExclusiveLock(Oid dbOid, Oid relOid)
{
    if (ENABLE_DMS) {
        return;
    }
    xl_standby_lock xlrec;
    xlrec.xid = GetTopTransactionId();
    /*
     * Decode the locktag back to the original values, to avoid sending lots
     * of empty bytes with every message.  See lock.h to check how a locktag
     * is defined for LOCKTAG_RELATION
     */
    xlrec.dbOid = dbOid;
    xlrec.relOid = relOid;
    LogAccessExclusiveLocks(1, &xlrec);
}