Hi, Tom! On Sun, Apr 10, 2016 at 7:49 AM, 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. 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? > > 2. Unless I'm missing something, contrib/bloom is making no effort > to ensure that bloom index pages can be distinguished from other pages > by pg_filedump. That's fine if your expectation is that bloom will always > be a toy with no use in production; but otherwise, not so much. You need > to make sure that the last two bytes of the page special space contain a > uniquely identifiable code; compare spgist_page_id in SPGiST indexes. > Thank you for spotting these issues. I'm going to prepare patches for fixing both of them. ------ Alexander Korotkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company
