On 1/21/22 18:04, Andres Freund wrote: > Hi, > > On 2022-01-21 17:42:45 -0500, Tom Lane wrote: >> Andrew Dunstan <and...@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
