pg_upgrade test writes to source directory
The 002_pg_upgrade.pl test leaves a file delete_old_cluster.sh in the
source directory. In vpath builds, there shouldn't be any files written
to the source directory.
Note that the TAP tests run with the source directory as the current
directory, so this is the result of pg_upgrade leaving its output files
in the current directory.
It looks like an addition of
chdir $ENV{TESTOUTDIR};
could fix it. Please check the patch.
Attachments:
0001-Run-pg_upgrade-test-in-build-directory.patchtext/plain; charset=UTF-8; name=0001-Run-pg_upgrade-test-in-build-directory.patchDownload+9-6
On Wed, May 25, 2022 at 08:21:26AM +0200, Peter Eisentraut wrote:
The 002_pg_upgrade.pl test leaves a file delete_old_cluster.sh in the source
directory. In vpath builds, there shouldn't be any files written to the
source directory.Note that the TAP tests run with the source directory as the current
directory, so this is the result of pg_upgrade leaving its output files in
the current directory.
Good catch, thanks.
It looks like an addition of
chdir $ENV{TESTOUTDIR};
could fix it. Please check the patch.
I think that you mean TESTDIR, and not TESTOUTDIR? Doing a chdir at
the beginning of the tests would cause pg_regress to fail as we would
not find anymore the regression schedule in a VPATH build, but it is
possible to chdir before the execution of pg_upgrade, like the
attached.
--
Michael
Attachments:
v2-0001-Run-pg_upgrade-test-in-build-directory.patchtext/x-diff; charset=us-asciiDownload+16-6
On 25.05.22 09:25, Michael Paquier wrote:
It looks like an addition of
chdir $ENV{TESTOUTDIR};
could fix it. Please check the patch.
I think that you mean TESTDIR, and not TESTOUTDIR?
I chose TESTOUTDIR because it corresponds to the tmp_check directory, so
that the output files of the pg_upgrade run are removed when the test
artifacts are cleaned up. When using TESTDIR, the pg_upgrade output
files end up in the build directory, which is less bad than the source
directory, but still not ideal.
On Thu, May 26, 2022 at 04:36:47PM +0200, Peter Eisentraut wrote:
I chose TESTOUTDIR because it corresponds to the tmp_check directory, so
that the output files of the pg_upgrade run are removed when the test
artifacts are cleaned up. When using TESTDIR, the pg_upgrade output files
end up in the build directory, which is less bad than the source directory,
but still not ideal.
Where does the choice of TESTOUTDIR come from? I am a bit surprised
by this choice, to be honest, because there is no trace of it in the
buildfarm client or the core code. TESTDIR, on the other hand, points
to tmp_check/ if not set. It gets set it in vcregress.pl and
Makefile.global.in.
--
Michael
On Fri, May 27, 2022 at 05:43:04AM +0900, Michael Paquier wrote:
On Thu, May 26, 2022 at 04:36:47PM +0200, Peter Eisentraut wrote:
I chose TESTOUTDIR because it corresponds to the tmp_check directory, so
that the output files of the pg_upgrade run are removed when the test
artifacts are cleaned up. When using TESTDIR, the pg_upgrade output files
end up in the build directory, which is less bad than the source directory,
but still not ideal.Where does the choice of TESTOUTDIR come from? I am a bit surprised
by this choice, to be honest, because there is no trace of it in the
buildfarm client or the core code. TESTDIR, on the other hand, points
to tmp_check/ if not set. It gets set it in vcregress.pl and
Makefile.global.in.
It looks like Peter working on top of the meson branch.
TESTOUTDIR is not yet in master.
https://commitfest.postgresql.org/38/3395/
https://github.com/anarazel/postgres/tree/meson
https://github.com/anarazel/postgres/commit/e754bde6d0d3cb6329a5bf568e19eb271c3bdc7c
commit e754bde6d0d3cb6329a5bf568e19eb271c3bdc7c
Author: Andres Freund <andres@anarazel.de>
Date: Mon Feb 14 21:47:07 2022 -0800
wip: split TESTDIR into two.
On Thu, May 26, 2022 at 03:52:18PM -0500, Justin Pryzby wrote:
It looks like Peter working on top of the meson branch.
TESTOUTDIR is not yet in master.
Thanks for the reference. I didn't know this part of the puzzle.
https://commitfest.postgresql.org/38/3395/
https://github.com/anarazel/postgres/tree/meson
https://github.com/anarazel/postgres/commit/e754bde6d0d3cb6329a5bf568e19eb271c3bdc7ccommit e754bde6d0d3cb6329a5bf568e19eb271c3bdc7c
Author: Andres Freund <andres@anarazel.de>
Date: Mon Feb 14 21:47:07 2022 -0800wip: split TESTDIR into two.
Well, we need to do something about that on HEAD, and it also means
that TESTDIR is the best fit for the job now, except if the variable
split happens before REL_15_STABLE is forked.
--
Michael
Michael Paquier <michael@paquier.xyz> writes:
On Thu, May 26, 2022 at 03:52:18PM -0500, Justin Pryzby wrote:
It looks like Peter working on top of the meson branch.
TESTOUTDIR is not yet in master.
Well, we need to do something about that on HEAD, and it also means
that TESTDIR is the best fit for the job now, except if the variable
split happens before REL_15_STABLE is forked.
It looks like that patch is meant to resolve misbehaviors equivalent to
this one that already exist in several other places. So fixing this
one along with the other ones seems like an appropriate thing to do
when that lands.
regards, tom lane
On Thu, May 26, 2022 at 06:19:56PM -0400, Tom Lane wrote:
It looks like that patch is meant to resolve misbehaviors equivalent to
this one that already exist in several other places. So fixing this
one along with the other ones seems like an appropriate thing to do
when that lands.
Well, would this specific change land in REL_15_STABLE? From what I
can see, generating delete_old_cluster.sh in the source rather than
the build directory is a defect from 322becb, as test.sh issues
pg_upgrade from the build path in ~14, but we do it from the source
path to get an access to parallel_schedule.
--
Michael
Michael Paquier <michael@paquier.xyz> writes:
On Thu, May 26, 2022 at 06:19:56PM -0400, Tom Lane wrote:
It looks like that patch is meant to resolve misbehaviors equivalent to
this one that already exist in several other places. So fixing this
one along with the other ones seems like an appropriate thing to do
when that lands.
Well, would this specific change land in REL_15_STABLE?
I wouldn't object to doing that, and even back-patching. It looked
like a pretty sane change, and we've learned before that skimping on
back-branch test infrastructure is a poor tradeoff.
regards, tom lane
On Thu, May 26, 2022 at 07:51:08PM -0400, Tom Lane wrote:
I wouldn't object to doing that, and even back-patching. It looked
like a pretty sane change, and we've learned before that skimping on
back-branch test infrastructure is a poor tradeoff.
Okay, fine by me. Andres, what do you think about backpatching [1]https://github.com/anarazel/postgres/commit/e754bde6d0d3cb6329a5bf568e19eb271c3bdc7c -- Michael?
[1]: https://github.com/anarazel/postgres/commit/e754bde6d0d3cb6329a5bf568e19eb271c3bdc7c -- Michael
--
Michael
On 26.05.22 22:52, Justin Pryzby wrote:
On Fri, May 27, 2022 at 05:43:04AM +0900, Michael Paquier wrote:
On Thu, May 26, 2022 at 04:36:47PM +0200, Peter Eisentraut wrote:
I chose TESTOUTDIR because it corresponds to the tmp_check directory, so
that the output files of the pg_upgrade run are removed when the test
artifacts are cleaned up. When using TESTDIR, the pg_upgrade output files
end up in the build directory, which is less bad than the source directory,
but still not ideal.Where does the choice of TESTOUTDIR come from? I am a bit surprised
by this choice, to be honest, because there is no trace of it in the
buildfarm client or the core code. TESTDIR, on the other hand, points
to tmp_check/ if not set. It gets set it in vcregress.pl and
Makefile.global.in.It looks like Peter working on top of the meson branch.
TESTOUTDIR is not yet in master.
Ooops, yeah. :)
I think you can just chdir to ${PostgreSQL::Test::Utils::tmp_check}.
On Fri, May 27, 2022 at 02:45:57PM +0200, Peter Eisentraut wrote:
I think you can just chdir to ${PostgreSQL::Test::Utils::tmp_check}.
Hmm. I think that I prefer your initial suggestion with TESTOUTDIR.
This sticks better in the long term, while making things consistent
with 010_tab_completion.pl, the only test that moves to TESTDIR while
running. So my vote would be to backpatch first the addition of
TESTOUTDIR, then fix the TAP test of pg_upgrade on HEAD to do the
same.
And I have just noticed that I completely forgot to add Andres about
this specific point, as meson is his work. So done now.
--
Michael
On 28.05.22 10:56, Michael Paquier wrote:
On Fri, May 27, 2022 at 02:45:57PM +0200, Peter Eisentraut wrote:
I think you can just chdir to ${PostgreSQL::Test::Utils::tmp_check}.
Hmm. I think that I prefer your initial suggestion with TESTOUTDIR.
This sticks better in the long term, while making things consistent
with 010_tab_completion.pl, the only test that moves to TESTDIR while
running. So my vote would be to backpatch first the addition of
TESTOUTDIR, then fix the TAP test of pg_upgrade on HEAD to do the
same.
I think it's a bit premature to talk about backpatching, since the patch
in question hasn't been committed anywhere yet, and AFAICT hasn't even
really been reviewed yet.
If you want to go this direction, I suggest you extract the patch and
present it here on its own merit. -- But then I might ask why such a
broad change post beta when apparently a one-line change would also work.
Hi,
On 2022-05-27 09:05:43 +0900, Michael Paquier wrote:
On Thu, May 26, 2022 at 07:51:08PM -0400, Tom Lane wrote:
I wouldn't object to doing that, and even back-patching. It looked
like a pretty sane change, and we've learned before that skimping on
back-branch test infrastructure is a poor tradeoff.Okay, fine by me. Andres, what do you think about backpatching [1]?
[1]: https://github.com/anarazel/postgres/commit/e754bde6d0d3cb6329a5bf568e19eb271c3bdc7c
Well, committing and backpatching ;)
I suspect there might be a bit more polish might be needed - that's why I
hadn't proposed the commit on its own yet. I was also wondering about
proposing a different split (test data, test logs).
I don't even know if we still need TESTDIR - since f4ce6c4d3a3 we add the
build dir to PATH, which IIUC was the reason for TESTDIR previously. Afaics
after f4ce6c4d3a3 and the TESTOUTDIR split the only TESTDIR use is in
src/tools/msvc/ecpg_regression.proj - so we could at least restrict it to
that.
Stuff I noticed on a quick skim:
# In a VPATH build, we'll be started in the source directory, but we want
# to run in the build directory so that we can use relative paths to
# access the tmp_check subdirectory; otherwise the output from filename
# completion tests is too variable.
Just needs a bit of rephrasing.
# Determine output directories, and create them. The base path is the
# TESTDIR environment variable, which is normally set by the invoking
# Makefile.
$tmp_check = $ENV{TESTOUTDIR} ? "$ENV{TESTOUTDIR}" : "tmp_check";
$log_path = "$tmp_check/log";
Probably just needs a s/TESTDIR/TESTOUTDIR/
Greetings,
Andres Freund
Andres Freund <andres@anarazel.de> writes:
I suspect there might be a bit more polish might be needed - that's why I
hadn't proposed the commit on its own yet.
Yeah, I'd noticed the obsoleted comments too, but not bothered to complain
since that was just WIP and not an officially proposed patch. I'll be
happy to review if you want to put up a full patch.
I was also wondering about
proposing a different split (test data, test logs).
Might be too invasive for back-patch.
regards, tom lane
On Sat, May 28, 2022 at 04:14:01PM -0400, Tom Lane wrote:
Yeah, I'd noticed the obsoleted comments too, but not bothered to complain
since that was just WIP and not an officially proposed patch. I'll be
happy to review if you want to put up a full patch.
Well, here is a formal patch set, then. Please feel free to comment.
FWIW, I am on the fence with dropping TESTDIR, as it could be used by
out-of-core test code as well. If there are doubts about
back-patching the first part, doing that only on HEAD would be fine to
fix the problem of this thread.
--
Michael
On 31.05.22 09:17, Michael Paquier wrote:
On Sat, May 28, 2022 at 04:14:01PM -0400, Tom Lane wrote:
Yeah, I'd noticed the obsoleted comments too, but not bothered to complain
since that was just WIP and not an officially proposed patch. I'll be
happy to review if you want to put up a full patch.Well, here is a formal patch set, then. Please feel free to comment.
FWIW, I am on the fence with dropping TESTDIR, as it could be used by
out-of-core test code as well. If there are doubts about
back-patching the first part, doing that only on HEAD would be fine to
fix the problem of this thread.
I don't understand the point of this first patch at all. Why define
TESTOUTDIR as a separate variable if it's always TESTDIR + tmp_check?
Why define TESTOUTDIR in pg_regress invocations, if nothing uses it? If
you want it as a separate variable, it could be defined in some Per
utility module, but I don't see why it needs to be in Makefile.global.
What is the problem that this is trying to solve?
Peter Eisentraut <peter.eisentraut@enterprisedb.com> writes:
On 31.05.22 09:17, Michael Paquier wrote:
Well, here is a formal patch set, then. Please feel free to comment.
FWIW, I am on the fence with dropping TESTDIR, as it could be used by
out-of-core test code as well. If there are doubts about
back-patching the first part, doing that only on HEAD would be fine to
fix the problem of this thread.
I don't understand the point of this first patch at all. Why define
TESTOUTDIR as a separate variable if it's always TESTDIR + tmp_check?
Why define TESTOUTDIR in pg_regress invocations, if nothing uses it? If
you want it as a separate variable, it could be defined in some Per
utility module, but I don't see why it needs to be in Makefile.global.
What is the problem that this is trying to solve?
Yeah, after looking this over it seems like we could drop 0001 and
just change 0002 to chdir into TESTDIR then into tmp_check. I'm not
sure I see the point of inventing a new global variable either,
and I'm definitely not happy with the proposed changes to
010_tab_completion.pl. My recollection is that those tests
were intentionally written to test tab completion involving a
directory name, but this change just loses that aspect entirely.
regards, tom lane
Hi,
On 2022-06-01 16:11:16 +0200, Peter Eisentraut wrote:
On 31.05.22 09:17, Michael Paquier wrote:
On Sat, May 28, 2022 at 04:14:01PM -0400, Tom Lane wrote:
Yeah, I'd noticed the obsoleted comments too, but not bothered to complain
since that was just WIP and not an officially proposed patch. I'll be
happy to review if you want to put up a full patch.Well, here is a formal patch set, then. Please feel free to comment.
FWIW, I am on the fence with dropping TESTDIR, as it could be used by
out-of-core test code as well. If there are doubts about
back-patching the first part, doing that only on HEAD would be fine to
fix the problem of this thread.I don't understand the point of this first patch at all. Why define
TESTOUTDIR as a separate variable if it's always TESTDIR + tmp_check? Why
define TESTOUTDIR in pg_regress invocations, if nothing uses it? If you
want it as a separate variable, it could be defined in some Per utility
module, but I don't see why it needs to be in Makefile.global. What is the
problem that this is trying to solve?
Until recently TESTDIR needed to point to the build directory containing the
binaries. But I'd like to be able to separate test log output from the build
tree, so that it's easier to capture files generated by tests for CI /
buildfarm. The goal is to have a separate directory for each test, so we can
present logs for failed tests separately. That was impossible with TESTDIR,
because it needed to point to the build directory.
Greetings,
Andres Freund
On Wed, Jun 01, 2022 at 02:11:12PM -0700, Andres Freund wrote:
Until recently TESTDIR needed to point to the build directory containing the
binaries. But I'd like to be able to separate test log output from the build
tree, so that it's easier to capture files generated by tests for CI /
buildfarm. The goal is to have a separate directory for each test, so we can
present logs for failed tests separately. That was impossible with TESTDIR,
because it needed to point to the build directory.
FWIW, this argument sounds sensible to me since I looked at 0001, not
only for the log files, but also to help in the capture of files
generated by the tests like 010_tab_completion.pl.
I don't know yet what to do about this part, so for now I have fixed
the other issue reported by Peter where the test names were missing.
--
Michael
