On 2017/09/07 8:51, Michael Paquier wrote: > On Thu, Sep 7, 2017 at 5:49 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: >> Amit Langote <langote_amit...@lab.ntt.co.jp> writes: >>> On 2017/08/22 9:39, Michael Paquier wrote: >>>> On Tue, Jun 27, 2017 at 4:56 PM, Amit Langote >>>> <langote_amit...@lab.ntt.co.jp> wrote: >>>>> I updated brin_mask() and spg_mask() in the attached updated patches so >>>>> that they consider meta pages as containing unused space. >> >> I looked briefly at these patches. I'm not sure that it's safe for the >> mask functions to assume that meta pages always have valid pd_lower. >> What happens when replaying log data concerning an old index that doesn't >> have that field filled? > > There will be inconsistency between the pages, and the masking check > will complain. My point here is that wal_consistency_checking is > primarily used by developers on newly-deployed clusters to check WAL > consistency by using installcheck. So an upgraded cluster would see > diffs because of that, but I would think that nobody would really face > them.
I too tend to think that any users who use this masking facility would know to expect to get these failures on upgraded clusters with invalid pd_lower in meta pages. (PS: I wonder if it is reasonable to allow configuring the error level used when a masking failure occurs? Currently, checkXLogConsistency() will abort the process (FATAL)) > Perhaps we should document this point for wal_consistency_check? Do you mean permanently under wal_consistency_check parameter documentation or in the release notes under incompatibilities for the affected index types? Thanks, Amit -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers