Re: meson and check-tests - Mailing list pgsql-hackers

From jian he
Subject Re: meson and check-tests
Date
Msg-id CACJufxGK6WSMR1i7E0Uw_QCs7aL6mSJ1xmu5n5Y1ekHKc+87Rg@mail.gmail.com
Whole thread Raw
In response to Re: meson and check-tests  (Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>)
List pgsql-hackers
On Wed, Jun 5, 2024 at 7:26 PM Ashutosh Bapat
<ashutosh.bapat.oss@gmail.com> wrote:
>
>
>
> On Mon, Jun 3, 2024 at 10:04 PM Tristan Partin <tristan@partin.io> wrote:
>>
>> On Sun Jun 2, 2024 at 12:25 AM CDT, Tom Lane wrote:
>> > "Tristan Partin" <tristan@partin.io> writes:
>> > > On Fri May 31, 2024 at 12:02 PM CDT, Ashutosh Bapat wrote:
>> > >> We talked this off-list at the conference. It seems we have to somehow
>> > >> avoid passing pg_regress --schedule argument and instead pass the list of
>> > >> tests. Any idea how to do that?
>> >
>> > > I think there are 2 solutions to this.
>> > > 1. Avoid passing --schedule by default, which doesn't sound like a great
>> > >    solution.
>> > > 2. Teach pg_regress to ignore the --schedule option if specific tests
>> > >    are passed instead.
>> > > 3. Add a --no-schedule option to pg_regress which would override the
>> > >    previously added --schedule option.
>> > > I personally prefer 2 or 3.
>
>
>
>
>>
>> >
>> > Just to refresh peoples' memory of what the Makefiles do:
>> > src/test/regress/GNUmakefile has
>> >
>> > check: all
>> >       $(pg_regress_check) $(REGRESS_OPTS) --schedule=$(srcdir)/parallel_schedule $(MAXCONNOPT) $(EXTRA_TESTS)
>> >
>> > check-tests: all | temp-install
>> >       $(pg_regress_check) $(REGRESS_OPTS) $(MAXCONNOPT) $(TESTS) $(EXTRA_TESTS)
>>
>> >
>> > (and parallel cases for installcheck etc).  AFAICS, meson.build has
>> > no equivalent to the EXTRA_TESTS add-on, nor does it have behavior
>> > equivalent to check-tests' substitution of $(TESTS) for --schedule.
>> > But I suggest that those behaviors have stood for a long time and
>> > so the appropriate thing to do is duplicate them as best we can,
>> > not invent something different.
>>
>> In theory, this makes sense. In practice, this is hard to emulate. We
>> could make the check-tests a Meson run_target() instead of another
>> test(), which would end up running the same tests more than once.
>
>
> meson has changed the way we run individual perl tests and that looks better. So I am fine if meson provides a better
wayto do what `make check-tests` does. But changing pg_regress seems a wrong choice or even making changes to the
currentmake system. Instead we should make meson pass the right arguments to pg_regress. In this case, it should not
pass--schedule when we need `make check-tests` like functionality. 
>
> Just adding check-tests as new target won't help we need some way to specify "which tests" to run. Thus by default
thistarget should not run any tests? I don't understand meson well. So I might be completely wrong? 
>
> How about the following options?
> 1. TESTS="..." meson test --suite regress - would run the specified tests from regress
>
> 2. Make `meson test --suite regress / regress/partition_join` run partition_join.sql test. I am not how to specify
multipletests in this command. May be `meson test --suite regress / regress/test_setup,partition_join` will do that.
makecheck-tests allows one to run multiple tests like TESTS="test_setup partition_join" make check-tests. 
>

hi. I think it's a good  feature for development.
The full regression test is still a very long time to run.

sometimes when you implement a feature, you are pretty sure some
changes will only happen in a single sql file.
so this can make it more faster.



pgsql-hackers by date:

Previous
From: Tender Wang
Date:
Subject: Re: Eager aggregation, take 3
Next
From: Amit Kapila
Date:
Subject: Re: Introduce XID age and inactive timeout based replication slot invalidation