Обсуждение: 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.

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

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/e754bde6d0d3cb6329a5bf568e19eb271c3bdc7c
>
> commit e754bde6d0d3cb6329a5bf568e19eb271c3bdc7c
> Author: Andres Freund <andres@anarazel.de>
> Date:   Mon Feb 14 21:47:07 2022 -0800
>
>     wip: 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]?

[1]: https://github.com/anarazel/postgres/commit/e754bde6d0d3cb6329a5bf568e19eb271c3bdc7c
--
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

On 2022-06-01 We 20:37, Michael Paquier wrote:
> 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.


I hope we fix the original issue soon - it's apparently been the cause
of numerous buildfarm failures that it was on my list to investigate
e.g.
<https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=jacana&dt=2022-05-15%2019%3A24%3A27>


cheers


andrew


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

On Thu, Jun 02, 2022 at 05:17:34PM -0400, Andrew Dunstan wrote:
> I hope we fix the original issue soon - it's apparently been the cause
> of numerous buildfarm failures that it was on my list to investigate
> e.g.
> <https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=jacana&dt=2022-05-15%2019%3A24%3A27>

Oops.  Thanks, Andrew, I was not aware of that.  I don't really want
to wait more if this impacts some of the buildfarm animals.  Even if
we don't conclude with the use of TESTOUTDIR for the time being, I see
no strong objections in using TESTDIR/tmp_check, aka
${PostgreSQL::Test::Utils::tmp_check}.  So I propose to apply a fix
doing that in the next 24 hours or so.  We can always switch to a
different path once we decide something else, if necessary.
--
Michael

On 2022-06-03 12:29:04 +0900, Michael Paquier wrote:
> On Thu, Jun 02, 2022 at 05:17:34PM -0400, Andrew Dunstan wrote:
> > I hope we fix the original issue soon - it's apparently been the cause
> > of numerous buildfarm failures that it was on my list to investigate
> > e.g.
> > <https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=jacana&dt=2022-05-15%2019%3A24%3A27>
> 
> Oops.  Thanks, Andrew, I was not aware of that.  I don't really want
> to wait more if this impacts some of the buildfarm animals.  Even if
> we don't conclude with the use of TESTOUTDIR for the time being, I see
> no strong objections in using TESTDIR/tmp_check, aka
> ${PostgreSQL::Test::Utils::tmp_check}.  So I propose to apply a fix
> doing that in the next 24 hours or so.  We can always switch to a
> different path once we decide something else, if necessary.

+1

Greetings,

Andres Freund

On Thu, Jun 02, 2022 at 08:50:12PM -0700, Andres Freund wrote:
> +1

OK, applied the extra chdir to PostgreSQL::Test::Utils::tmp_check, as
initially suggested by Peter.  The CI looked happy on that.
--
Michael

Hi,

On 2022-06-01 10:55:28 -0400, Tom Lane wrote:
> [...] 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.

How about creating a dedicated directory for the created files, to maintain
that? My goal of being able to redirect the test output elsewhere can be
achieved with just a hunk like this:

@@ -70,11 +70,13 @@ delete $ENV{LS_COLORS};
 # 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.
-if ($ENV{TESTDIR})
+if ($ENV{TESTOUTDIR})
 {
-    chdir $ENV{TESTDIR} or die "could not chdir to \"$ENV{TESTDIR}\": $!";
+    chdir "$ENV{TESTOUTDIR}" or die "could not chdir to \"$ENV{TESTOUTDIR}\": $!";
 }
 
+mkdir "tmp_check" unless -d "tmp_check";
+
 # Create some junk files for filename completion testing.
 my $FH;
 open $FH, ">", "tmp_check/somefile"


Of course it'd need a comment adjustment etc. It's a bit ugly to use a
otherwise empty tmp_check/ directory just to reduce the diff size, but it's
also not too bad.

Greetings,

Andres Freund

Andres Freund <andres@anarazel.de> writes:
> On 2022-06-01 10:55:28 -0400, Tom Lane wrote:
>> [...] 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.

> How about creating a dedicated directory for the created files, to maintain
> that? My goal of being able to redirect the test output elsewhere can be
> achieved with just a hunk like this:

Sure, there's no need for these files to be in the exact same place that
the output is collected.  I just want to keep their same relationship
to the test's CWD.

> Of course it'd need a comment adjustment etc. It's a bit ugly to use a
> otherwise empty tmp_check/ directory just to reduce the diff size, but it's
> also not too bad.

Given that it's no longer going to be the same tmp_check dir used
elsewhere, maybe we could s/tmp_check/tab_comp_dir/g or something
like that?  That'd add some clarity I think.

            regards, tom lane

Hi,

On 2022-08-11 11:26:39 -0400, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> > On 2022-06-01 10:55:28 -0400, Tom Lane wrote:
> >> [...] 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.
>
> > How about creating a dedicated directory for the created files, to maintain
> > that? My goal of being able to redirect the test output elsewhere can be
> > achieved with just a hunk like this:
>
> Sure, there's no need for these files to be in the exact same place that
> the output is collected.  I just want to keep their same relationship
> to the test's CWD.
>
> > Of course it'd need a comment adjustment etc. It's a bit ugly to use a
> > otherwise empty tmp_check/ directory just to reduce the diff size, but it's
> > also not too bad.
>
> Given that it's no longer going to be the same tmp_check dir used
> elsewhere, maybe we could s/tmp_check/tab_comp_dir/g or something
> like that?  That'd add some clarity I think.

Done in the attached patch (0001).

A bunch of changes (e.g. f4ce6c4d3a3) made since I'd first written that
TESTOUTDIR patch means that we don't need two different variables anymore. So
patch 0002 just moves the addition of /tmp_check from Utils.pm to the places
in which TESTDIR is defined.

That still "forces" tmp_check/ to exist when going through pg_regress, but
that's less annoying because pg_regress at least keeps
regression.{diffs,out}/log files/directory outside of tmp_check/.

I've also attached a 0003 that splits the log location from the data
location. That could be used to make the log file location symmetrical between
pg_regress (log/) and tap tests (tmp_check/log).  But it'd break the
buildfarm's tap test log file collection, so I don't think that's something we
really can do soon-ish?

Greetings,

Andres Freund

Hi,

On 2022-08-15 20:20:51 -0700, Andres Freund wrote:
> On 2022-08-11 11:26:39 -0400, Tom Lane wrote:
> > Andres Freund <andres@anarazel.de> writes:
> > > On 2022-06-01 10:55:28 -0400, Tom Lane wrote:
> > >> [...] 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.
> >
> > > How about creating a dedicated directory for the created files, to maintain
> > > that? My goal of being able to redirect the test output elsewhere can be
> > > achieved with just a hunk like this:
> >
> > Sure, there's no need for these files to be in the exact same place that
> > the output is collected.  I just want to keep their same relationship
> > to the test's CWD.
> >
> > > Of course it'd need a comment adjustment etc. It's a bit ugly to use a
> > > otherwise empty tmp_check/ directory just to reduce the diff size, but it's
> > > also not too bad.
> >
> > Given that it's no longer going to be the same tmp_check dir used
> > elsewhere, maybe we could s/tmp_check/tab_comp_dir/g or something
> > like that?  That'd add some clarity I think.
> 
> Done in the attached patch (0001).
> 
> A bunch of changes (e.g. f4ce6c4d3a3) made since I'd first written that
> TESTOUTDIR patch means that we don't need two different variables anymore. So
> patch 0002 just moves the addition of /tmp_check from Utils.pm to the places
> in which TESTDIR is defined.
> 
> That still "forces" tmp_check/ to exist when going through pg_regress, but
> that's less annoying because pg_regress at least keeps
> regression.{diffs,out}/log files/directory outside of tmp_check/.
> 
> I've also attached a 0003 that splits the log location from the data
> location. That could be used to make the log file location symmetrical between
> pg_regress (log/) and tap tests (tmp_check/log).  But it'd break the
> buildfarm's tap test log file collection, so I don't think that's something we
> really can do soon-ish?

Oops, 0003 had some typos in it that I added last minute... Corrected patches
attached.

Greetings,

Andres Freund

Andres Freund <andres@anarazel.de> writes:
> On 2022-08-11 11:26:39 -0400, Tom Lane wrote:
>> Given that it's no longer going to be the same tmp_check dir used
>> elsewhere, maybe we could s/tmp_check/tab_comp_dir/g or something
>> like that?  That'd add some clarity I think.

> Done in the attached patch (0001).

I was confused by 0001, because with the present test setup that will
result in creating an extra tab_comp_dir that isn't inside tmp_check,
leading to needing cleanup infrastructure that isn't there.  However,
0002 clarifies that: you're redefining TESTDIR.  I think 0001 is OK
as long as you apply it after, or integrate it into, 0002.

> patch 0002 just moves the addition of /tmp_check from Utils.pm to the places
> in which TESTDIR is defined.

I see some references to TESTDIR in src/tools/msvc/ecpg_regression.proj.
It looks like those are not references to this variable but uses of the

 <PropertyGroup>
  <TESTDIR>..\..\interfaces\ecpg\test</TESTDIR>

thingy at the top of the file.  Still, it's a bit confusing --- should
we rename that?  Maybe not worth the trouble given the short expected
lifespan of the MSVC test scripts.  0002 seems fine otherwise.

> I've also attached a 0003 that splits the log location from the data
> location. That could be used to make the log file location symmetrical between
> pg_regress (log/) and tap tests (tmp_check/log).  But it'd break the
> buildfarm's tap test log file collection, so I don't think that's something we
> really can do soon-ish?

No particular opinion about 0003 -- as you say, that's going to be
gated by the buildfarm.

            regards, tom lane

On 2022-08-15 Mo 23:20, Andres Freund wrote:
>
> I've also attached a 0003 that splits the log location from the data
> location. That could be used to make the log file location symmetrical between
> pg_regress (log/) and tap tests (tmp_check/log).  But it'd break the
> buildfarm's tap test log file collection, so I don't think that's something we
> really can do soon-ish?


Where would you like to have the buildfarm client search? Currently it
does this:


    my @logs = glob("$dir/tmp_check/log/*");

    $log->add_log($_) foreach (@logs);

I can add another pattern in that glob expression. I'm intending to put
out a new release pretty soon (before US Labor Day).


cheers


andrew


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

Hi,

On 2022-08-16 11:33:12 -0400, Andrew Dunstan wrote:
> On 2022-08-15 Mo 23:20, Andres Freund wrote:
> >
> > I've also attached a 0003 that splits the log location from the data
> > location. That could be used to make the log file location symmetrical between
> > pg_regress (log/) and tap tests (tmp_check/log).  But it'd break the
> > buildfarm's tap test log file collection, so I don't think that's something we
> > really can do soon-ish?
> 
> 
> Where would you like to have the buildfarm client search? Currently it
> does this:
> 
> 
>     my @logs = glob("$dir/tmp_check/log/*");
> 
>     $log->add_log($_) foreach (@logs);
> 
> I can add another pattern in that glob expression. I'm intending to put
> out a new release pretty soon (before US Labor Day).

$dir/log, so it's symmetric to the location of log files of regress/isolation
tests.

Thanks!

Andres