Re: pg_combinebackup PITR comparison test fix - Mailing list pgsql-hackers

From Dagfinn Ilmari Mannsåker
Subject Re: pg_combinebackup PITR comparison test fix
Date
Msg-id 87ed276cg1.fsf@wibble.ilmari.org
Whole thread Raw
In response to pg_combinebackup PITR comparison test fix  (Dagfinn Ilmari Mannsåker <ilmari@ilmari.org>)
List pgsql-hackers
Michael Paquier <michael@paquier.xyz> writes:

> On Sun, Dec 15, 2024 at 10:34:07AM +0900, Michael Paquier wrote:
>> Indeed, good catch.  I'll take care of it.

Thanks!

> +    sub {
> +        s{create tablespace .* location '.*/tspitr\K[12]}{N}i for @_;
> +        return $_[0] ne $_[1];
> +    });
>
> The CI is complaining on this one because the custom comparison
> function is not able to digest WIN32 paths, leading to failures in the
> dump comparison like that:
> -CREATE TABLESPACE ts1 OWNER "SYSTEM" LOCATION
> E'C:\\Windows\\TEMP\\tJ4qTmrkZv\\tspitr1';
> +CREATE TABLESPACE ts1 OWNER "SYSTEM" LOCATION
> E'C:\\Windows\\TEMP\\tJ4qTmrkZv\\tspitr2';
>
> So there is an issue with the slash character after the location and
> the single space before the quote.  We could use something like this
> one which would handle the paths sanely:
> s{create tablespace .* location .*'.*tspitr\K[12]}{N}i for @_;
>
> Perhaps you are able to come with a more elegant string?

I'm torn between making it more specific, only allowing escaped strings
or not, and either type of slash for the path separator:

s{create tablespace .* location .* E?'.*[\\/]tspitr\K[12]}{N}i for @_;

vs. making it less specific, not caring about the specifics of quoting
or path separators at all:

s{create tablespace .* location .*\btspitr\K[12]}{N}i for @_;

I think I'm leaning towards the latter, for simplicity and robustness.

- ilmari



pgsql-hackers by date:

Previous
From: "Ryohei Takahashi (Fujitsu)"
Date:
Subject: RE: COPY performance on Windows
Next
From: torikoshia
Date:
Subject: Re: Enhancing Memory Context Statistics Reporting