Re: Transaction Snapshots and Hot Standby

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

In response to

Browse pgsql-hackers by date

  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