On 1/21/22 18:04, Andres Freund wrote:
> Hi,
>
> On 2022-01-21 17:42:45 -0500, Tom Lane wrote:
>> Andrew Dunstan <andrew@dunslane.net> writes:
>>> c.f. src/bin/pg_verifybackup/t/003_corruption.pl which says:
>>> my $source_ts_prefix = $source_ts_path;
>>> $source_ts_prefix =~ s!(^[A-Z]:/[^/]*)/.*!$1!;
>>> ...
>>> # See https://www.msys2.org/wiki/Porting/#filesystem-namespaces
>>> local $ENV{MSYS2_ARG_CONV_EXCL} = $source_ts_prefix;
>>> Probably in this case just setting it to 'server:' would do the trick.
>> The point I was trying to make is that if we have to jump through
>> that sort of hoop in the test scripts, then real users are going
>> to have to jump through it as well, and they won't like that
>> (and we will get bug reports about it). It'd be better to design
>> the option syntax to avoid such requirements.
> Normal users aren't going to invoke a "native" basebackup from inside msys. I
> assume the translation happens because an "msys world" perl invokes
> a "native" pg_basebackup via msys system(), right? If pg_basebackup instead is
> "normally" invoked from a windows terminal, or anything else "native" windows,
> the problem won't exist, no?
>
> As we're building a "native" postgres in this case, none of our tools should
> internally have such translations happening. So I don't think it'll be a huge
> issue for users themselves?
All true. This is purely an issue for our testing regime, and not for
end users.
>
> Not that I think that there are all that many users of mingw built postgres on
> windows... I think it's mostly msvc built postgres in that world?
>
The vast majority use the installer which is built with MSVC. Very few
in my experience build their own.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
