Re: fairywren is generating bogus BASE_BACKUP commands

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: fairywren is generating bogus BASE_BACKUP commands
Date: 2022-01-23 19:48:55
Message-ID: CA+TgmobX4Yvc8eV+N3MAc7nMyQ102sgcu=WpD0wr93mx6Gdd8g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, Jan 23, 2022 at 12:20 PM Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:

> It's not as simple as that :-( But you're on the right track. My
> suggestion above doesn't work.
>
> The rule for paths is: when you're passing a path to an external program
> that's not msys aware (typically, one of our build artefacts like psql
> or pg_basebackup) it needs to be a native path. But when you're passing
> it to a perl function (e.g. mkdir) or to an external program that's msys
> aware it needs to be a virtual path, i.e. one not mangled by perl2host.
>
> Some recent commits to this file especially have not obeyed this rule.
> Here's a patch that does it consistently for the whole file. I have
> tested it on a system very like fairywren, and the test passes.

I can't understand how this would prevent server:/what/ever from
getting turned into server;c:\what\ever. But if it does, great!

Maybe we need to have a README in the tree somewhere that tries to
explain this. Or maybe we should make our build artifacts msys-aware,
if that's possible, so that this just works. Or maybe supporting msys
is not worth the trouble.

--
Robert Haas
EDB: http://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2022-01-23 19:59:50 Re: Bogus duplicate command issued in pg_dump
Previous Message David G. Johnston 2022-01-23 19:39:27 Re: Bogus duplicate command issued in pg_dump