Re: pgsql: Force run of pg_upgrade in the build directory in its TAP test - Mailing list pgsql-committers

From Michael Paquier
Subject Re: pgsql: Force run of pg_upgrade in the build directory in its TAP test
Date
Msg-id YqkhANbVO13UNXxR@paquier.xyz
Whole thread Raw
In response to Re: pgsql: Force run of pg_upgrade in the build directory in its TAP test  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: pgsql: Force run of pg_upgrade in the build directory in its TAP test  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-committers
On Tue, Jun 14, 2022 at 01:23:04PM -0400, Tom Lane wrote:
> I suppose it would be too user-unfriendly to generate those scripts
> underneath $PGDATA, so don't we need to put back the .gitignore
> entries?

delete_old_cluster.sh is generated within tmp_check/ in a non-VPATH
build:
$ cd src/bin/pg_upgrade/ && make check
$ find . -name delete_old_cluster.sh
./tmp_check/delete_old_cluster.sh
$ git grep chdir -- *.pl
t/002_pg_upgrade.pl:chdir ${PostgreSQL::Test::Utils::tmp_check};

Or you have a workflow where you do a "make clean" after running the
tests on a past stable branch?  This would leave behind
delete_old_cluster.sh, especially if the cleanup is triggered on
HEAD.  With each branch taken in isolation, there is no need for a
.gitignore entry.  (FWIW, I just use a worktree these days in my flow
of patching across multiple stable branches.)
--
Michael

Attachment

pgsql-committers by date:

Previous
From: Tom Lane
Date:
Subject: pgsql: Avoid ecpglib core dump with out-of-order operations.
Next
From: Tom Lane
Date:
Subject: Re: pgsql: Force run of pg_upgrade in the build directory in its TAP test