From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Peter Geoghegan <pg(at)bowt(dot)ie> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Minor meson gripe |
Date: | 2023-02-10 01:17:00 |
Message-ID: | 20230210011700.ogd6jcohncztufqt@awork3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On 2023-02-09 17:00:48 -0800, Peter Geoghegan wrote:
> On Thu, Feb 9, 2023 at 4:33 PM Andres Freund <andres(at)anarazel(dot)de> wrote:
> > I e.g. have a not-quite-done patch that creates a "template initdb", which
> > pg_regress and tap tests automatically use (except if non-default options are
> > required), which quite noticably reduces test times (*). But something needs to
> > create the template initdb, and initdb doesn't run without an installation, so
> > we need to run it after the temp_install.
> >
> > Of course we could wrap that into one "test", but it seemed nicer to see if
> > you fail during installation, or during initdb. So for that I added a separate
> > test, that is also part of the setup suite.
>
> But what are the chances that the setup / tmp_install "test" will
> actually fail? It's almost a test in name only.
I've seen more failures than I'd like. Permission errors, conflicting names,
and similar things. But mainly that was a reference to running initdb, which
I've broken temporarily many a time.
> > Of course we could still name the suite tmp_install (or to be consistent with
> > the confusing make naming, have a temp-install target, which creates the
> > tmp_install directory :)). I guess that'd still be less confusing?
>
> Yes, that definitely seems like an improvement. I don't care about the
> tiny inconsistency that this creates.
Then lets do that - feel free to push something, or send something for
review. Otherwise I'll try to get to it, but I owe a few people work before
this...
> I wonder if this could be addressed by adding another custom test
> setup, like --setup running, used whenever you want to just run one or
> two tests against an ad-hoc temporary installation? Offhand it seems
> as if add_test_setup() could support that requirement?
What precisely do you mean with "ad-hoc temporary installation"?
I was wondering about adding a different setup that'd use the "real"
installation to run tests. But perhaps that's something different than what
you have in mind?
The only restriction I see wrt add_test_setup() is that it's not entirely
trivial to use a "runtime-variable" path to an installation.
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Jeff Davis | 2023-02-10 01:22:47 | Re: ICU locale validation / canonicalization |
Previous Message | Peter Smith | 2023-02-10 01:10:46 | Re: [PATCH] Add pretty-printed XML output option |