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 ) id 1pTkDh-0001QR-PN for pgsql-hackers@arkaria.postgresql.org; Sun, 19 Feb 2023 13:59:13 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1pTkDg-0006sw-9O for pgsql-hackers@arkaria.postgresql.org; Sun, 19 Feb 2023 13:59:12 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pTkDf-0006sm-Vx for pgsql-hackers@lists.postgresql.org; Sun, 19 Feb 2023 13:59:11 +0000 Received: from relay4-d.mail.gandi.net ([217.70.183.196]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pTkDY-0007Q3-Ef for pgsql-hackers@postgresql.org; Sun, 19 Feb 2023 13:59:10 +0000 Received: (Authenticated sender: adsend@dunslane.net) by mail.gandi.net (Postfix) with ESMTPSA id 36C7CE0002; Sun, 19 Feb 2023 13:59:00 +0000 (UTC) Content-Type: multipart/alternative; boundary="------------NcOcOJ1Y7XxfWAghFI8NbtLU" Message-ID: Date: Sun, 19 Feb 2023 08:58:59 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.5.0 Subject: Re: Handle TEMP_CONFIG for pg_regress style tests in pg_regress.c Content-Language: en-US To: Peter Eisentraut , Andres Freund , pgsql-hackers@postgresql.org References: <20230218202611.cp7ke2tz5lnafu5z@awork3.anarazel.de> <48568ed7-1ccd-0ca9-aa31-e51e9df2c99d@enterprisedb.com> From: Andrew Dunstan In-Reply-To: <48568ed7-1ccd-0ca9-aa31-e51e9df2c99d@enterprisedb.com> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk This is a multi-part message in MIME format. --------------NcOcOJ1Y7XxfWAghFI8NbtLU Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 2023-02-19 Su 02:25, Peter Eisentraut wrote: > On 18.02.23 21:26, Andres Freund wrote: >> When building with meson, TEMP_CONFIG is supported for TAP tests, but >> doesn't >> do anything for regress/isolation. >> >> The reason for that is that meson's (and ninja's) architecture is to >> separate >> "build setup" from the "build/test/whatever" stage, moving dynamism >> (and more >> costly operations) to the "setup" phase. >> >> In this case the implication is that the command line for the test isn't >> re-computed dynamically. But pg_regress doesn't look at TEMP_CONFIG, >> it just >> has a --temp-config=... parameter, that src/Makefile.global.in >> dynamically >> adds if TEMP_CONFIG is set. >> >> In contrast to that, TEMP_CONFIG support for tap tests is implemented in >> Cluster.pm, and thus works transparently. >> >> My inclination is to move TEMP_CONFIG support from the Makefile to >> pg_regress.c. That way it's consistent across the build tools and isn't >> duplicated. pg_regress already looks at a bunch of temporary variables >> (e.g. PG_REGRESS_SOCK_DIR, PG_TEST_USE_UNIX_SOCKETS), so this isn't >> really >> breaking new ground. > > I'm having a hard time understanding what TEMP_CONFIG is for.  It > appears that the intention is to allow injecting arbitrary > configuration into the tests?  In that case, I think your proposal > makes sense.  But I don't see this documented, so who knows what it is > actually used for. > > > It started here quite a long time ago: commit 0cb74d3cec Author: Andrew Dunstan Date:   Sun Sep 9 20:40:54 2007 +0000     Provide for a file specifying non-standard config options for temp install     for pg_regress, via --temp-config option. Pick this up in the make file     via TEMP_CONFIG setting. It's used by the buildfarm to add the extra config settings from its configuration file. cheers andrew -- Andrew Dunstan EDB:https://www.enterprisedb.com --------------NcOcOJ1Y7XxfWAghFI8NbtLU Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit


On 2023-02-19 Su 02:25, Peter Eisentraut wrote:
On 18.02.23 21:26, Andres Freund wrote:
When building with meson, TEMP_CONFIG is supported for TAP tests, but doesn't
do anything for regress/isolation.

The reason for that is that meson's (and ninja's) architecture is to separate
"build setup" from the "build/test/whatever" stage, moving dynamism (and more
costly operations) to the "setup" phase.

In this case the implication is that the command line for the test isn't
re-computed dynamically. But pg_regress doesn't look at TEMP_CONFIG, it just
has a --temp-config=... parameter, that src/Makefile.global.in dynamically
adds if TEMP_CONFIG is set.

In contrast to that, TEMP_CONFIG support for tap tests is implemented in
Cluster.pm, and thus works transparently.

My inclination is to move TEMP_CONFIG support from the Makefile to
pg_regress.c. That way it's consistent across the build tools and isn't
duplicated. pg_regress already looks at a bunch of temporary variables
(e.g. PG_REGRESS_SOCK_DIR, PG_TEST_USE_UNIX_SOCKETS), so this isn't really
breaking new ground.

I'm having a hard time understanding what TEMP_CONFIG is for.  It appears that the intention is to allow injecting arbitrary configuration into the tests?  In that case, I think your proposal makes sense.  But I don't see this documented, so who knows what it is actually used for.




It started here quite a long time ago:


commit 0cb74d3cec
Author: Andrew Dunstan <andrew@dunslane.net>
Date:   Sun Sep 9 20:40:54 2007 +0000

    Provide for a file specifying non-standard config options for temp install
    for pg_regress, via --temp-config option. Pick this up in the make file
    via TEMP_CONFIG setting.

It's used by the buildfarm to add the extra config settings from its configuration file.


cheers


andrew


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