Re: More issues with pg_verify_checksums and checksum verification in base backups

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Stephen Frost <sfrost(at)snowman(dot)net>
Cc: Andres Freund <andres(at)anarazel(dot)de>, David Steele <david(at)pgmasters(dot)net>, Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>, pgsql-hackers(at)postgresql(dot)org, andrew(at)dunslane(dot)net, daniel(at)yesql(dot)se, magnus(at)hagander(dot)net, tgl(at)sss(dot)pgh(dot)pa(dot)us
Subject: Re: More issues with pg_verify_checksums and checksum verification in base backups
Date: 2018-11-28 01:32:11
Message-ID: 20181128013211.GA626@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Nov 27, 2018 at 08:17:12PM -0500, Stephen Frost wrote:
> * Michael Paquier (michael(at)paquier(dot)xyz) wrote:
>> Please see 0002 attached, which moves the call to skipfile() where I
>> think it should go.
>
> Alright, on a quick glance that seems ok.

Thanks.

>> Base backups are impacted as well as this causes spurious warnings.
>
> Right- could you please also add comments around the two lists to make
> other hackers aware that the list shows up in two places and that any
> changes should be made in both places..?

Good point. Added in my local branch.

>> Attached are two patches to fix all the mess:
>> - 0001 is a revert of the whitelist, minus the set of regression tests
>> checking after corrupted files and empty files.
>> - 0002 is a fix for all the issues reported on this thread, with tests
>> added (including the tablespace test from Michael Banck):
>> -- Base backups gain EXEC_BACKEND files in their warning filters.
>> -- pg_verify_checksums gains the same files.
>> -- temporary files are filtered out.
>> -- pg_verify_checksums performs filtering checks only on regular files,
>> not on paths.
>>
>> 0001 and 0002 need to be merged as 0001 would cause the buildfarm to
>> turn red on Windows if applied alone. Can you know see my point?
>
> Yes, I think they could be merged to address that, though I'm not sure
> that it's necessairly a huge deal either, if they're going to be pushed
> together.

This avoids noise failures when bisecting a regression, which matters in
some cases. To keep the history cleaner perhaps you are right and it
would be cleaner to split into two commits.

Let's wait a bit and see if others have extra opinions to offer.
--
Michael

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Sanyo Moura 2018-11-28 01:36:09 Re: Query with high planning time at version 11.1 compared versions 10.5 and 11.0
Previous Message Justin Pryzby 2018-11-28 01:27:13 Re: Query with high planning time at version 11.1 compared versions 10.5 and 11.0