Re: pg_combinebackup PITR comparison test fix

From: Dagfinn Ilmari Mannsåker <ilmari(at)ilmari(dot)org>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: pg_combinebackup PITR comparison test fix
Date: 2024-12-16 12:26:38
Message-ID: 87ed276cg1.fsf@wibble.ilmari.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Michael Paquier <michael(at)paquier(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message torikoshia 2024-12-16 12:51:53 Re: Enhancing Memory Context Statistics Reporting
Previous Message Ryohei Takahashi (Fujitsu) 2024-12-16 12:10:03 RE: COPY performance on Windows