Re: Handle TEMP_CONFIG for pg_regress style tests in pg_regress.c - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: Handle TEMP_CONFIG for pg_regress style tests in pg_regress.c
Date
Msg-id 48568ed7-1ccd-0ca9-aa31-e51e9df2c99d@enterprisedb.com
Whole thread Raw
In response to Handle TEMP_CONFIG for pg_regress style tests in pg_regress.c  (Andres Freund <andres@anarazel.de>)
Responses Re: Handle TEMP_CONFIG for pg_regress style tests in pg_regress.c
List pgsql-hackers
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.




pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: shoud be get_extension_schema visible?
Next
From: Nitin Jadhav
Date:
Subject: Re: Inconsistency in reporting checkpointer stats