Re: Add extension options to control TAP and isolation tests

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Nikolay Shaplov <dhyan(at)nataraj(dot)su>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org, Adam Berlin <berlin(dot)ab(at)gmail(dot)com>
Subject: Re: Add extension options to control TAP and isolation tests
Date: 2018-11-23 00:43:45
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On Thu, Nov 22, 2018 at 10:01:26PM +0300, Nikolay Shaplov wrote:
> В письме от 21 ноября 2018 09:39:53 пользователь Michael Paquier написал:
>> Those are mentioned here as part of the additional test suites:
> Oh thanks (I feel urge to start editing documentation right now. I will
> surpress it, and do it, I hope, later.)

If you have a patch to improve the existing docs, please feel free to
submit those on a different thread. If you have suggestions about
improving this patch's docs, of course please feel free to suggest them

> May I also ask a question, I came across. It is not part of the patch, but
> nevertheless...
> If I look in the code, regression test are sql files with expected output that
> are in src/test/regress. If I look in the documentation, all the tests are
> regression tests including TAP tests.
> what is the right way to look at it?

That's for the main regression test suite within src/test/regress, TAP
is also a regression test suite, the page of the link reflects the
general set of test suites available.

> So, I continued exploring your patch. First I carefully read changes in
> The only part of it I did not understand is
> .PHONY: submake
> -submake:
> ifndef PGXS
> +submake:
> +ifdef REGRESS
> $(MAKE) -C $(top_builddir)/src/test/regress pg_regress$(X)
> endif
> +ifdef ISOLATION
> + $(MAKE) -C $(top_builddir)/src/test/isolation all
> +endif
> +endif # PGXS

This is to make sure that the necessary tools are compiled before
running the related tests. "submake:" needs to be moved out actually.
Thinking about it a bit more, we should also remove the "ifdef REGRESS"
and "ifdef ISOLATION" because there are some dependencies here. For
example TAP tests call pg_regress to initialize connection policy. TAP
tests may also use isolation_tester or such.

> I suppose it is because the purpose of PGXS is never explained, not in the
> documentation, not in the code comments, and PGXS := $(shell $(PG_CONFIG) --
> pgxs) sounds like some strange magic spell, that explains nothing. In what
> cases it is defined? In what cases it is not defined? What exactly does it
> store? Can we make things more easy to understand here?

That's part of a larger scope which is here:

> 2. As far as you said that TAP tests for bloom were never executed,
> I guess I should just ignore
> -
> -wal-check: temp-install
> - (prove_check)
> as a part of wrong way to execute TAP tests. (I fond no traces of "wal-check"
> string in the code, so I guess this build target is an invention of bloom
> authors)

Yes. It seems that it was useful for debugging at this time, but this
will rot if let as-is... I am pretty sure that most people don't use
that wrapper.

> 3. The rest are trivial, except changes for contrib/test_decoding/ and
> src/test/modules/brin I will explore them in my next postgres-dev time slot
> and then my review work will be done :-)

Thanks for the input, Nikolay!

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Stephen Frost 2018-11-23 02:02:35 Re: row filtering for logical replication
Previous Message David Rowley 2018-11-23 00:16:46 Re: Speeding up INSERTs and UPDATEs to partitioned tables