On Sun, Apr 10, 2016 at 7:49 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
1. It doesn't seem like generic_xlog.c has thought very carefully about the semantics of the "hole" between pd_lower and pd_upper. The mainline XLOG code goes to some lengths to ensure that the hole stays all-zeroes; for example RestoreBlockImage() explicitly zeroes the hole when restoring from a full-page image that has a hole. But generic_xlog.c's redo routine does not do anything comparable, nor does GenericXLogFinish make any effort to ensure that the "hole" is all-zeroes after normal application of a generic update. The reason this is of interest is that it means the contents of the "hole" could diverge between master and slave, or differ between the original state of a database and what it is after a crash and recovery. That would at least complicate forensic comparisons of pages, and I think it might also break checksumming. We thought that this was important enough to take the trouble of explicitly zeroing holes during mainline XLOG replay. Shouldn't generic_xlog.c take the same trouble?
Attached patch is intended to fix this. It zeroes "hole" in both GenericXLogFinish() and generic_redo().
