From: | "Florian G(dot) Pflug" <fgp(at)phlo(dot)org> |
---|---|
To: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
Cc: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Transaction Snapshots and Hot Standby |
Date: | 2008-09-15 18:22:42 |
Message-ID: | 48CEA7F2.9070700@phlo.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2008-09-15 20:27:11 | Re: Transaction Snapshots and Hot Standby |
Previous Message | Florian G. Pflug | 2008-09-15 18:20:08 | Re: Transaction Snapshots and Hot Standby |