On Sun, Apr 10, 2016 at 1:49 PM, Tom Lane <t...@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.
Yes. > 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? One look at checksum_impl.h shows up that the page hole is taken into account in the checksum calculation, so we definitely has better zero the page. And looking at generic_xlog.c, this code either logs in a full page, or a delta. Actually, as I look at this code for the first time, I find that GenericXLogFinish() is a very confusing interface. It makes no distinction between a page and the meta data associated to this page, this is controlled by a flag isNew and buffer data is saved as some delta. Actually, fullmage is not exactly true, this may refer to a page that has a hole. It seems to me that we should not have one but two routines: GenericXLogRegisterBuffer and GenericXLogRegisterBufData, similar to what the normal XLOG routines offer. -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
