> 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.
So passing xl_xmin from master to standby seems not necessary to me. The
standby's OldestXmin needs to be passed through to the master, not the
other way around so that WAL records for tuple removal are not
generated.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
No comments:
Post a Comment