Re: Some other things about contrib/bloom and generic_xlog.c - Mailing list pgsql-hackers

From Alexander Korotkov
Subject Re: Some other things about contrib/bloom and generic_xlog.c
Date
Msg-id CAPpHfdu_U7rd8NZk0s5YA+QtATjVf-b9iyue2yh6hTVDPniCvQ@mail.gmail.com
Whole thread Raw
In response to Some other things about contrib/bloom and generic_xlog.c  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Hi, Tom!

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?

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

pgsql-hackers by date:

Previous
From: Teodor Sigaev
Date:
Subject: Re: Some other things about contrib/bloom and generic_xlog.c
Next
From: Tom Lane
Date:
Subject: Re: Some other things about contrib/bloom and generic_xlog.c