From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, 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-02-04 01:51:31 |
Message-ID: | 20220204015131.mijsnymuzg4u4c6x@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On 2022-02-03 17:25:51 -0500, Andrew Dunstan wrote:
> OK, I have all the pieces working and I know what I need to do to adapt
> fairywren. The patch you provided is not necessary any more.
Cool. Are you going to post that?
> (I think your TMPDIR spec is missing a /build/)
I think I went back/forth between in-tree/out-of-tree build...
> The recipe worked (mutatis mutandis) for the mingw64 toolchain as well
> as for the ucrt64 toolchain. Is there a reason to prefer ucrt64?
There's a lot of oddities in the mingw64 target, due to targetting the much
older C runtime library (lots of bugs, missing functionality). MSVC targets
UCRT by default for quite a few years by now. Targetting msvcrt is basically
on its way out from what I understand.
> I think the next steps are:
>
> * do those two reverts
> * adjust fairywren
> * get rid of perl2host
>
> At that stage jacana will no longer be able to run TAP tests. I can do
> one of these:
I guess because its install is too old?
> * disable the TAP tests on jacana
> * migrate jacana to msys2
> * kiss jacana goodbye.
Having a non-server mingw animal seems like it could be useful (I think that's
just Jacana), even if server / client versions of windows have grown
closer. So I think an update to msys2 makes the most sense?
> > To make tests in "in-tree" builds work, a bit more hackery would be
> > needed. The problem is that windows chooses binaries from the current working
> > directory *before* PATH. That's a problem for things like initdb.exe or
> > pg_ctl.exe that want to find postgres.exe, as that only works with the program
> > in their proper location, rather than CWD.
> Yeah, we should do something about that. For example, we could possibly
> use the new install_path option of PostgreSQL::Test::Cluster::new() so
> it would find these in the right location.
It'd be easy enough to adjust the central invocations of initdb. I think the
bigger problem is that there's plenty calls to initdb, pg_ctl "directly" in
the respective test scripts.
> However, I don't need it as my animals all use vpath builds.
I think it'd be fine to just error out in non-vpath builds on msvc. The
search-for-binaries behaviour is just too weird.
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Fujii Masao | 2022-02-04 01:59:04 | Re: Add checkpoint and redo LSN to LogCheckpointEnd log message |
Previous Message | Alvaro Herrera | 2022-02-04 01:42:32 | Re: support for CREATE MODULE |