Re: fairywren is generating bogus BASE_BACKUP commands

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Andres Freund <andres(at)anarazel(dot)de>
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-03 22:25:51
Message-ID: 50f00b9a-51af-2ee2-d8f4-82f7887413f8@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


On 1/24/22 21:36, Andres Freund wrote:
> Hi,
>
> On 2022-01-24 16:47:28 -0500, Andrew Dunstan wrote:
>> Give me what you can and I'll see what I can do. I have a couple of
>> moderately high priority items on my plate, but I will probably be able
>> to fit in some testing when those make my eyes completely glaze over.
> Steps:
>
> # install msys from https://www.msys2.org/
> # install dependencies in msys shell
> pacman -S git bison flex make ucrt64/mingw-w64-ucrt-x86_64-perl ucrt64/mingw-w64-ucrt-x86_64-gcc ucrt64/mingw-w64-ucrt-x86_64-zlib ucrt64/mingw-w64-ucrt-x86_64-ccache diffutils
>
>
> # start mingw ucrt64 x64 shell
> cpan install -T IPC::Run
> perl -MIPC::Run -e 1 # verify ipc run is installed
>
> cd /c/dev
> # I added --reference postgres to accelerate the cloning
> git clone https://git.postgresql.org/git/postgresql.git postgres-mingw
> cd /c/dev/postgres-mingw
>
> git revert ed52c3707bcf8858defb0d9de4b55f5c7f18fed7
> git revert 6051857fc953a62db318329c4ceec5f9668fd42a
>
> # apply attached patch
>
> # see below why out-of-tree is easier or now
> mkdir build
> cd build
> # path parameters probably not necessary, I thought I needed them earlier, not sure why
> ../configure --without-readline --cache cache --enable-tap-tests PROVE=/ucrt64/bin/core_perl/prove PERL=/ucrt64/bin/perl.exe CC="ccache gcc"
> make -j8 -s world-bin && make -j8 -s -C src/interfaces/ecpg/test
> make -j8 -s temp-install
>
> # pg_regress' make_temp_socketdir() otherwise picks up the wrong TMPDIR
> mkdir /c/dev/postgres-mingw/build/tmp
>
> # the TAR= ensures that tests pick up a tar accessible with a windows path
> # PG_TEST_USE_UNIX_SOCKETS=1 is required for test concurrency, otherwise there are port conflicts
>
> (make -Otarget -j12 check-world NO_TEMP_INSTALL=1 PG_TEST_USE_UNIX_SOCKETS=1 TMPDIR=C:/dev/postgres-mingw/tmp TAR="C:\Windows\System32\tar.exe" 2>&1 && echo test-world-success || echo test-world-fail) 2>&1 |tee test-world.log

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.

(I think your TMPDIR spec is missing a /build/)

The recipe worked (mutatis mutandis) for the mingw64 toolchain as well
as for the ucrt64 toolchain. Is there a reason to prefer ucrt64?

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:

* disable the TAP tests on jacana
* migrate jacana to msys2
* kiss jacana goodbye.

Thoughts?

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

However, I don't need it as my animals all use vpath builds.

cheers

andrew

--
Andrew Dunstan
EDB: https://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Nathan Bossart 2022-02-04 00:03:40 Re: Avoid erroring out when unable to remove or parse logical rewrite files to save checkpoint work
Previous Message John Naylor 2022-02-03 22:07:48 Re: do only critical work during single-user vacuum?