On 09/04/2015 09:30 PM, Simon Riggs wrote:
On 4 September 2015 at 13:45, Heikki Linnakangas <hlinn...@iki.fi> wrote:
Another issue was with the new speculative insertions. Replaying a
speculative insertion record sets the tuple's CTID to point to itself, like
in a regular insertion. But in the original system, the CTID is set to a
special speculative insertion token. The tool flagged up that difference.
I propose the attached patch (mark-speculative-insertions-in-replay.patch)
to fix that in the replay routine. This is not required for correctness,
but helps this tool, and seems like a good idea for debugging purposes
anyway.
ISTM that the WAL record should include the speculative insertion token, so
that replay can set it correctly.
I view this the same as command IDs. We don't restore the original
command ID of a tuple at WAL replay either, because it's irrelevant for
recovery and hot standby.
That way we can always re-check that the later update matches the
speculative insertion token we expect, in all cases.
Hmm, I guess that would give a tiny bit of extra sanity checking at
replay. Doesn't really seem worth the trouble and extra WAL volume to me.
In any case, the assumption that we are replaying all changes in single
threaded mode is not appropriate for use with logical replication.
No such assumption here AFAICS.
- Heikki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
