prevent 006_transfer_modes.pl from leaving files behind
The other pg_upgrade tests chdir to tmp_check prior to running pg_upgrade
to avoid leaving behind delete_old_cluster.{sh,bat}. 006_transfer_modes.pl
should, too. However, this test is a little different because it loops
over all of the available transfer modes and runs pg_upgrade for each one
supported by the platform. From my testing and code analysis, it seems
sufficient to change the directory once at the beginning of the test, but
we could alternatively save the current directory and change back to it in
each iteration to be safe.
Thoughts?
--
nathan
Attachments:
v1-0001-Fix-the-006_transfer_modes.pl-test.patchtext/plain; charset=us-asciiDownload
From a349a98b19708984dc677e5809038d343d67bf17 Mon Sep 17 00:00:00 2001
From: Nathan Bossart <nathan@postgresql.org>
Date: Mon, 7 Apr 2025 16:23:44 -0500
Subject: [PATCH v1 1/1] Fix the 006_transfer_modes.pl test.
This test was leaving files like delete_old_cluster.sh in the
source directory for VPATH and meson builds. To fix, change the
directory to tmp_check before running the test, as was done in
commits 15b6d21553, 8af917be6b, and c462b054ba.
Oversight in commit af0d4901c1.
Reported-by: Andrew Dunstan <andrew@dunslane.net> (on Discord)
Discussion: ???
---
src/bin/pg_upgrade/t/006_transfer_modes.pl | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/src/bin/pg_upgrade/t/006_transfer_modes.pl b/src/bin/pg_upgrade/t/006_transfer_modes.pl
index 34fddbcdab5..ed713a7d44d 100644
--- a/src/bin/pg_upgrade/t/006_transfer_modes.pl
+++ b/src/bin/pg_upgrade/t/006_transfer_modes.pl
@@ -102,6 +102,11 @@ sub test_mode
$new->clean_node();
}
+# In a VPATH build, we'll be started in the source directory, but we want
+# to run pg_upgrade in the build directory so that any files generated finish
+# in it, like delete_old_cluster.{sh,bat}.
+chdir ${PostgreSQL::Test::Utils::tmp_check};
+
test_mode('--clone');
test_mode('--copy');
test_mode('--copy-file-range');
--
2.39.5 (Apple Git-154)
On Mon, Apr 07, 2025 at 04:45:52PM -0500, Nathan Bossart wrote:
The other pg_upgrade tests chdir to tmp_check prior to running pg_upgrade
to avoid leaving behind delete_old_cluster.{sh,bat}. 006_transfer_modes.pl
should, too. However, this test is a little different because it loops
over all of the available transfer modes and runs pg_upgrade for each one
supported by the platform. From my testing and code analysis, it seems
sufficient to change the directory once at the beginning of the test, but
we could alternatively save the current directory and change back to it in
each iteration to be safe.Thoughts?
Hmm. Doing one chdir at the beginning of the test should be OK,
because we don't do a move to a different directory within the test
for each transfer mode tested. So your patch looks like the simplest
thing to do to avoid the generation of these files. Note that
delete_old_cluster.sh would be left around even if not using a VPATH
build with ./configure (your commit message does not mention that).
Even if .gitignore discards it, the file is here.
--
Michael
On 2025-04-07 Mo 7:41 PM, Michael Paquier wrote:
On Mon, Apr 07, 2025 at 04:45:52PM -0500, Nathan Bossart wrote:
The other pg_upgrade tests chdir to tmp_check prior to running pg_upgrade
to avoid leaving behind delete_old_cluster.{sh,bat}. 006_transfer_modes.pl
should, too. However, this test is a little different because it loops
over all of the available transfer modes and runs pg_upgrade for each one
supported by the platform. From my testing and code analysis, it seems
sufficient to change the directory once at the beginning of the test, but
we could alternatively save the current directory and change back to it in
each iteration to be safe.Thoughts?
Hmm. Doing one chdir at the beginning of the test should be OK,
because we don't do a move to a different directory within the test
for each transfer mode tested. So your patch looks like the simplest
thing to do to avoid the generation of these files. Note that
delete_old_cluster.sh would be left around even if not using a VPATH
build with ./configure (your commit message does not mention that).
Even if .gitignore discards it, the file is here.
I don't think that matters. In non-vpath builds we expect the source
directory to be scribbled on. All sorts of things might be left around.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
Andrew Dunstan <andrew@dunslane.net> writes:
On 2025-04-07 Mo 7:41 PM, Michael Paquier wrote:
delete_old_cluster.sh would be left around even if not using a VPATH
build with ./configure (your commit message does not mention that).
Even if .gitignore discards it, the file is here.
I don't think that matters. In non-vpath builds we expect the source
directory to be scribbled on. All sorts of things might be left around.
It's okay as long as .gitignore ignores it and "make clean" removes it.
When/if we give up makefile builds, a lot of these maintenance
issues will go away...
regards, tom lane
On 2025-04-08 Tu 10:17 AM, Tom Lane wrote:
Andrew Dunstan <andrew@dunslane.net> writes:
On 2025-04-07 Mo 7:41 PM, Michael Paquier wrote:
delete_old_cluster.sh would be left around even if not using a VPATH
build with ./configure (your commit message does not mention that).
Even if .gitignore discards it, the file is here.I don't think that matters. In non-vpath builds we expect the source
directory to be scribbled on. All sorts of things might be left around.It's okay as long as .gitignore ignores it and "make clean" removes it.
When/if we give up makefile builds, a lot of these maintenance
issues will go away...
Maybe some will, but I observed the present issue on fairywren which is
using meson.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com