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