posrgresql 中的 multi-transaction-log

其实主要是当把多个事务ID看作一个事务ID时，给这多个事务的集合一个multi的事务ID，这个事务ID不是普通的事务ID，有专有用途，

MultiXactId 也是32整数，为了把事务的集合存起来，需要两个文件，一个是存集合的偏移，另一个存集合中的事务ID，集合的大小没存，是通过相邻的偏移计算的，存放在数据库目录下的 pg_multixact 下

/*<br> * The pg_multixact manager is a pg_clog-like manager that stores an array<br> * of TransactionIds for each MultiXactId. It is a fundamental part of the<br> * shared-row-lock implementation. A share-locked tuple stores a<br> * MultiXactId in its Xmax, and a transaction that needs to wait for the<br> * tuple to be unlocked can sleep on the potentially-several TransactionIds<br> * that compose the MultiXactId.<br> */<br>

 共享内存中的，主要是为下次分配记录起始位置

/*<br> * MultiXact state shared across all backends. All this state is protected<br> * by MultiXactGenLock. (We also use MultiXactOffsetControlLock and<br> * MultiXactMemberControlLock to guard accesses to the two sets of SLRU<br> * buffers. For concurrency’s sake, we avoid holding more than one of these<br> * locks at a time.)<br> */<br> typedef struct MultiXactStateData<br> {<br> /* next-to-be-assigned MultiXactId */<br> MultiXactId nextMXact;

/* next-to-be-assigned offset */
MultiXactOffset nextOffset;

/* the Offset SLRU area was last truncated at this MultiXactId */
MultiXactId lastTruncationPoint;

/*
* Per-backend data starts here. We have two arrays stored in the area
* immediately following the MultiXactStateData struct. Each is indexed by
* BackendId.
*
* In both arrays, there’s a slot for all normal backends (1..MaxBackends)
* followed by a slot for max_prepared_xacts prepared transactions. Valid
* BackendIds start from 1; element zero of each array is never used.
*
* OldestMemberMXactId[k] is the oldest MultiXactId each backend’s current
* transaction(s) could possibly be a member of, or InvalidMultiXactId
* when the backend has no live transaction that could possibly be a
* member of a MultiXact. Each backend sets its entry to the current
* nextMXact counter just before first acquiring a shared lock in a given
* transaction, and clears it at transaction end. (This works because only
* during or after acquiring a shared lock could an XID possibly become a
* member of a MultiXact, and that MultiXact would have to be created
* during or after the lock acquisition.)
*
* OldestVisibleMXactId[k] is the oldest MultiXactId each backend’s
* current transaction(s) think is potentially live, or InvalidMultiXactId
* when not in a transaction or not in a transaction that’s paid any
* attention to MultiXacts yet. This is computed when first needed in a
* given transaction, and cleared at transaction end. We can compute it
* as the minimum of the valid OldestMemberMXactId[] entries at the time
* we compute it (using nextMXact if none are valid). Each backend is
* required not to attempt to access any SLRU data for MultiXactIds older
* than its own OldestVisibleMXactId[] setting; this is necessary because
* the checkpointer could truncate away such data at any instant.
*
* The checkpointer can compute the safe truncation point as the oldest
* valid value among all the OldestMemberMXactId[] and
* OldestVisibleMXactId[] entries, or nextMXact if none are valid.
* Clearly, it is not possible for any later-computed OldestVisibleMXactId
* value to be older than this, and so there is no risk of truncating data
* that is still needed.
*/
MultiXactId perBackendXactIds[1]; /* VARIABLE LENGTH ARRAY */
} MultiXactStateData;

偏移是通过在共享内存中LRU算法8个页面，集合事务ID是在共享内存中LRU算法16个页面。

转载自：https://blog.csdn.net/spche/article/details/5998064