| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
| Cc: | Andres Freund <andres(at)anarazel(dot)de>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Anastasia Lubennikova <lubennikovaav(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: A test for replay of regression tests |
| Date: | 2021-12-16 00:22:40 |
| Message-ID: | YbqG0DsKGRBnY/4t@paquier.xyz |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, Dec 15, 2021 at 05:50:45PM +0900, Michael Paquier wrote:
> Hmm. FWIW, I am working on doing similar for pg_upgrade to switch to
> TAP there, and we share a lot in terms of running pg_regress on an
> exising cluster. Wouldn't it be better to move this definition to
> src/Makefile.global.in rather than src/test/recovery/?
>
> My pg_regress command is actually very similar to yours, so I am
> wondering if this would be better if somehow centralized, perhaps in
> Cluster.pm.
By the way, while I was sorting out my things, I have noticed that v4
does not handle EXTRA_REGRESS_OPT. Is that wanted? You could just
add that into your patch set and push the extra options to the
pg_regress command:
my $extra_opts_val = $ENV{EXTRA_REGRESS_OPT} || "";
my @extra_opts = split(/\s+/, $extra_opts_val);
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Soumyadeep Chakraborty | 2021-12-16 01:01:24 | Re: Unnecessary delay in streaming replication due to replay lag |
| Previous Message | Tom Lane | 2021-12-15 23:58:59 | Re: Life cycles of tuple descriptors |