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
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 |