Thread

Commits

  1. Split TESTDIR into TESTLOGDIR and TESTDATADIR

  2. Don't hardcode tmp_check/ as test directory for tap tests

  3. Force run of pg_upgrade in the build directory in its TAP test

  4. Add missing test names in TAP tests of pg_upgrade

  1. pg_upgrade test writes to source directory

    Peter Eisentraut <peter.eisentraut@enterprisedb.com> — 2022-05-25T06:21:26Z

    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.
  2. Re: pg_upgrade test writes to source directory

    Michael Paquier <michael@paquier.xyz> — 2022-05-25T07:25:24Z

    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
    
  3. Re: pg_upgrade test writes to source directory

    Peter Eisentraut <peter.eisentraut@enterprisedb.com> — 2022-05-26T14:36:47Z

    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.
    
    
    
    
  4. Re: pg_upgrade test writes to source directory

    Michael Paquier <michael@paquier.xyz> — 2022-05-26T20:43:04Z

    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
    
  5. Re: pg_upgrade test writes to source directory

    Justin Pryzby <pryzby@telsasoft.com> — 2022-05-26T20:52:18Z

    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.
    
    
    
    
  6. Re: pg_upgrade test writes to source directory

    Michael Paquier <michael@paquier.xyz> — 2022-05-26T22:03:30Z

    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
    
  7. Re: pg_upgrade test writes to source directory

    Tom Lane <tgl@sss.pgh.pa.us> — 2022-05-26T22:19:56Z

    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
    
    
    
    
  8. Re: pg_upgrade test writes to source directory

    Michael Paquier <michael@paquier.xyz> — 2022-05-26T23:23:50Z

    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
    
  9. Re: pg_upgrade test writes to source directory

    Tom Lane <tgl@sss.pgh.pa.us> — 2022-05-26T23:51:08Z

    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
    
    
    
    
  10. Re: pg_upgrade test writes to source directory

    Michael Paquier <michael@paquier.xyz> — 2022-05-27T00:05:43Z

    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
    
  11. Re: pg_upgrade test writes to source directory

    Peter Eisentraut <peter.eisentraut@enterprisedb.com> — 2022-05-27T12:45:57Z

    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}.
    
    
    
    
  12. Re: pg_upgrade test writes to source directory

    Michael Paquier <michael@paquier.xyz> — 2022-05-28T08:56:30Z

    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
    
  13. Re: pg_upgrade test writes to source directory

    Peter Eisentraut <peter.eisentraut@enterprisedb.com> — 2022-05-28T18:29:27Z

    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.
    
    
    
    
  14. Re: pg_upgrade test writes to source directory

    Andres Freund <andres@anarazel.de> — 2022-05-28T19:59:49Z

    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
    
    
    
    
  15. Re: pg_upgrade test writes to source directory

    Tom Lane <tgl@sss.pgh.pa.us> — 2022-05-28T20:14:01Z

    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
    
    
    
    
  16. Re: pg_upgrade test writes to source directory

    Michael Paquier <michael@paquier.xyz> — 2022-05-31T07:17:01Z

    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
    
  17. Re: pg_upgrade test writes to source directory

    Peter Eisentraut <peter.eisentraut@enterprisedb.com> — 2022-06-01T14:11:16Z

    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?
    
    
    
    
    
    
  18. Re: pg_upgrade test writes to source directory

    Tom Lane <tgl@sss.pgh.pa.us> — 2022-06-01T14:55:28Z

    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
    
    
    
    
  19. Re: pg_upgrade test writes to source directory

    Andres Freund <andres@anarazel.de> — 2022-06-01T21:11:12Z

    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
    
    
    
    
  20. Re: pg_upgrade test writes to source directory

    Michael Paquier <michael@paquier.xyz> — 2022-06-02T00:37:58Z

    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
    
  21. Re: pg_upgrade test writes to source directory

    Andrew Dunstan <andrew@dunslane.net> — 2022-06-02T21:17:34Z

    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
    
    
    
    
    
  22. Re: pg_upgrade test writes to source directory

    Michael Paquier <michael@paquier.xyz> — 2022-06-03T03:29:04Z

    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
    
  23. Re: pg_upgrade test writes to source directory

    Andres Freund <andres@anarazel.de> — 2022-06-03T03:50:12Z

    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
    
    
    
    
  24. Re: pg_upgrade test writes to source directory

    Michael Paquier <michael@paquier.xyz> — 2022-06-04T03:21:42Z

    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
    
  25. Re: pg_upgrade test writes to source directory

    Andres Freund <andres@anarazel.de> — 2022-08-11T15:20:28Z

    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
    
    
    
    
  26. Re: pg_upgrade test writes to source directory

    Tom Lane <tgl@sss.pgh.pa.us> — 2022-08-11T15:26:39Z

    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
    
    
    
    
  27. Re: pg_upgrade test writes to source directory

    Andres Freund <andres@anarazel.de> — 2022-08-16T03:20:51Z

    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
    
  28. Re: pg_upgrade test writes to source directory

    Andres Freund <andres@anarazel.de> — 2022-08-16T05:14:47Z

    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
    
  29. Re: pg_upgrade test writes to source directory

    Tom Lane <tgl@sss.pgh.pa.us> — 2022-08-16T14:58:16Z

    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
    
    
    
    
  30. Re: pg_upgrade test writes to source directory

    Andrew Dunstan <andrew@dunslane.net> — 2022-08-16T15:33:12Z

    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
    
    
    
    
    
  31. Re: pg_upgrade test writes to source directory

    Andres Freund <andres@anarazel.de> — 2022-08-16T15:42:32Z

    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