Received: from malur.postgresql.org ([217.196.149.56])
	by arkaria.postgresql.org with esmtps
 (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256)
	(Exim 4.92)
	(envelope-from <pgsql-hackers-owner+archive@lists.postgresql.org>)
	id 1oNy1W-0007Py-NM
	for pgsql-hackers@arkaria.postgresql.org; Tue, 16 Aug 2022 14:58:30 +0000
Received: from localhost ([127.0.0.1] helo=malur.postgresql.org)
	by malur.postgresql.org with esmtp (Exim 4.92)
	(envelope-from <pgsql-hackers-owner+archive@lists.postgresql.org>)
	id 1oNy1T-0004O1-Qv
	for pgsql-hackers@arkaria.postgresql.org; Tue, 16 Aug 2022 14:58:27 +0000
Received: from makus.postgresql.org ([2001:4800:3e1:1::229])
	by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256)
	(Exim 4.92)
	(envelope-from <tgl@sss.pgh.pa.us>)
	id 1oNy1T-0004My-HF
	for pgsql-hackers@lists.postgresql.org; Tue, 16 Aug 2022 14:58:27 +0000
Received: from sss.pgh.pa.us ([66.207.139.130])
	by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256)
	(Exim 4.92)
	(envelope-from <tgl@sss.pgh.pa.us>)
	id 1oNy1N-0002IQ-It
	for pgsql-hackers@postgresql.org; Tue, 16 Aug 2022 14:58:23 +0000
Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1])
	by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 27GEwGWK1131991;
	Tue, 16 Aug 2022 10:58:17 -0400
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
cc: Peter Eisentraut <peter.eisentraut@enterprisedb.com>,
        Michael Paquier <michael@paquier.xyz>,
        Justin Pryzby <pryzby@telsasoft.com>, pgsql-hackers@postgresql.org
Subject: Re: pg_upgrade test writes to source directory
In-reply-to: <20220816032051.ya7ieuteaq2h6g2m@awork3.anarazel.de>
References: <YpAMBqPrusng47e0@paquier.xyz> <2480063.1653609068@sss.pgh.pa.us>
 <YpAV1y8CUXGGkPJQ@paquier.xyz>
 <20220528195949.tte5fukfr2z6xhrr@alap3.anarazel.de>
 <3131727.1653768841@sss.pgh.pa.us> <YpXA7XHZtunxalTr@paquier.xyz>
 <e65a862a-24aa-7482-6d98-49fbb048f22f@enterprisedb.com>
 <571133.1654095328@sss.pgh.pa.us>
 <20220811152028.znxm5fpxjhe43hzw@awork3.anarazel.de>
 <11298.1660231599@sss.pgh.pa.us>
 <20220816032051.ya7ieuteaq2h6g2m@awork3.anarazel.de>
Comments: In-reply-to Andres Freund <andres@anarazel.de>
	message dated "Mon, 15 Aug 2022 20:20:51 -0700"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1131989.1660661896.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Tue, 16 Aug 2022 10:58:16 -0400
Message-ID: <1131990.1660661896@sss.pgh.pa.us>
List-Id: <pgsql-hackers.lists.postgresql.org>
List-Help: <https://lists.postgresql.org/manage/>
List-Subscribe: <https://lists.postgresql.org/manage/>
List-Post: <mailto:pgsql-hackers@lists.postgresql.org>
List-Owner: <mailto:pgsql-hackers-owner@lists.postgresql.org>
List-Archive: <https://www.postgresql.org/list/pgsql-hackers>
Archived-At: 
 <https://www.postgresql.org/message-id/1131990.1660661896%40sss.pgh.pa.us>
Precedence: bulk

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 pl=
aces
> 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 b=
etween
> 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 someth=
ing 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