Re: Handle TEMP_CONFIG for pg_regress style tests in pg_regress.c

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Handle TEMP_CONFIG for pg_regress style tests in pg_regress.c
Date: 2023-02-19 16:13:38
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> On 2023-02-19 Su 02:25, Peter Eisentraut wrote:
>> On 18.02.23 21:26, Andres Freund wrote:
>>> 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.

>> I'm having a hard time understanding what TEMP_CONFIG is for.

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

I have also used it manually to inject configuration changes into
TAP tests, for instance running them with debug_discard_caches = 1.
It's quite handy, but I agree the lack of documentation is bad.

It looks to me like pg_regress already does implement this; that
is, the Makefiles convert TEMP_CONFIG into a --temp-config switch
to pg_[isolation_]regress. So if we made pg_regress responsible
for examining the envvar directly, very little new code would be
needed. (Maybe net negative code if we remove the command line
switch, but I'm not sure if we should.) What we'd lose is the
ability to write
make TEMP_CONFIG=foo check
but I wouldn't miss that. Having a uniform rule that TEMP_CONFIG
is an environment variable and nothing else seems good.

regards, tom lane

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Tomas Vondra 2023-02-19 17:10:13 Re: Add LZ4 compression in pg_dump
Previous Message Tomas Vondra 2023-02-19 15:04:16 Re: Ignoring BRIN for HOT updates (was: -udpates seems broken)