Jeff Davis wrote:
On Wed, 2007-06-06 at 22:36 +0100, Simon Riggs wrote:
.) Transactions are assigned a dummy xid ReadOnlyTransactionId, that
is considered to be "later" than any other xid.
So you are bumping FirstNormalTransactionId up by one for this?
You're assuming then that we will "freeze" replay while we run a query?
Otherwise doing this will mean the snapshot changes as a query executes.
Is it possible to put a normal xmax for the snapshot?
It wouldn't be a real transaction on the slave, and also the master will
use that ID for a real transaction itself. However, I don't see a real
problem on the slave because it would only be used for the purpose of
the snapshot we need at that moment.
My plan is the following:
.) Initially, queries and recovery will run interleaved, but not concurrently.
For that, an "empty" snapshot is sufficient, with
xmin=xid=xmax=ReadOnlyTransactionId.
.) Then, I'll work on running them concurrently. The replay process will publish
a "current" snapshot in shared memory, using "real" xmin and xmax values
it generates by maintaining a list of currently active (as in: running when
the wal was written on the master) transactions. In that case, only xid
is set to ReadOnlyTransactionId.
greetings, Florian Pflug
---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
