Re: pgsql: Add TAP tests for pg_verify_checksums - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: pgsql: Add TAP tests for pg_verify_checksums
Date
Msg-id d986613b-992c-2400-78d8-08e21dff337c@2ndQuadrant.com
Whole thread Raw
In response to Re: pgsql: Add TAP tests for pg_verify_checksums  (Michael Paquier <michael@paquier.xyz>)
Responses Re: pgsql: Add TAP tests for pg_verify_checksums  (Michael Paquier <michael@paquier.xyz>)
List pgsql-hackers

On 10/13/2018 09:59 PM, Michael Paquier wrote:
> On Sat, Oct 13, 2018 at 05:53:00PM -0400, Andrew Dunstan wrote:
>> It occurred to me that a pretty simple fix could just be to blacklist
>> everything that didn't start with a digit. The whitelist approach is
>> probably preferable... depends how urgent we see this as.
> Yeah, possibly, still that's not a correct long-term fix.  So attached
> is what I think we should do for HEAD and REL_11_STABLE with an approach
> using a whitelist.  I have added positive and negative tests on top of
> the existing TAP tests, as suggested by Michael B, and I made the code
> use relpath.h to make sure that we don't miss any fork types.
>
> Any objections to this patch?



This code now seems redundant:

          if (strcmp(fn, ".") == 0 ||
              strcmp(fn, "..") == 0)
              return true;


I would probably reverse the order of these two tests. It might not make 
any difference, assuming fn is never an empty string, but it seems more 
logical to me.

    +    /* good to go if only digits */
    +    if (fn[pos] == '\0')
    +        return false;
    +    /* leave if no digits */
    +    if (pos == 0)
    +        return true;

It also looks to me like the check for a segment number doesn't ensure there is at least one digit, so "123." might
pass,but I could be wrong. In any case, there isn't a test for that, and there probably should be.
 

cheers

andrew


-- 
Andrew Dunstan                https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



pgsql-hackers by date:

Previous
From: Thomas Munro
Date:
Subject: Re: Experimenting with hash join prefetch
Next
From: Justin Pryzby
Date:
Subject: rowcount estimate varies WRT partitionwise_join