Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes:
> BTW, we haven't talked about how to acquire a snapshot in the slave. You'll
> somehow need to know which transactions have not yet committed, but will in the
> future.
I'm not sure why you need to know which ones will commit in the future. ISTM
you need the same information you normally have which is just which ones have
committed as of the point of WAL replay you're at.
However it does occur to me that if you know in advance that a transaction
will abort in the future you could skip applying its WAL records when you see
them. I'm not sure it's worth adding such an optimization though and it might
get weird around vacuum.
> In the master, we keep track of in-progress transaction in the ProcArray, so
> I suppose we'll need to do the same in the slave. Very similar to prepared
> transactions, actually. I believe the Abort records, which are not actually
> needed for normal operation, become critical here. The slave will need to
> put an entry to ProcArray for any new XLogRecord.xl_xid it sees in the WAL,
> and remove the entry at a Commit and Abort record. And clear them all at a
> shutdown record.
That's how I envisioned it when the topic came up, but another solution was
also bandied about -- I'm not sure who originally proposed it. The alternative
method is to have the master periodically insert a data structure describing a
snapshot in the WAL. The slave then keeps a copy of the last snapshot it saw
in the WAL and any new query which starts up uses that.
-- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's PostGIS support!
