On 7/16/12, Steven Schlansker <steven@likeness.com> wrote:
> I think it's pretty easy to show that timestamp+size isn't good enough to do
> this 100% reliably.
That may not be a problem if the slave server synchronization code
always starts to play back WAL entries at a time before the worst case
for timestamp precision.
I'm assuming here that the WAL playback process works something like this:
Look at a WAL entry, see if the disk block it references matches the
'before' indicators for that block in the WAL. If so, update it to
the 'after' data content.
There are two non-matching conditions:
If the disk block information indicates that it should match a later
update, then that block does not need to be updated.
But if the disk block information indicates that it should match an
earlier update than the one in the WAL entry, then the synchronization
fails.
