Simon Riggs wrote:
> On Sat, 2008-09-13 at 10:48 +0100, Florian G. Pflug wrote:
>
>> The current read-only snapshot (which "current" meaning the
>> corresponding state on the master at the time the last replayed wal
>> record was generated) was maintained in shared memory. It' xmin field
>> was continually updated with the (newly added) XLogRecord.xl_xmin
>> field, which contained the xid of the oldest running query on the
>> master, with a pruning step after each ReadOnlySnapshot.xmin update to
>> remove all entries < xmin from the xid array. If a commit was seen for
>> an xid, that xid was added to the ReadOnlySnapshot.xid array.
>>
>> The advantage of this concept is that it handles snapshotting on the
>> slave without too much additional work for the master (The only change
>> is the addition of the xl_xmin field to XLogRecord). It especially
>> removes that need to track ShmemVariableCache->nextXid.
>
> Snapshots only need to know which transactions are currently "running"
> during WAL apply. The standby can't remove any tuples itself, so it
> doesn't need to know what the master's OldestXmin is.
I used the logged xmin value to track the shared snapshot's xmin, which
in turn allowed me to prune the xid array, eliminating all xids < that xmin.
regards, Florian Pflug
