Re: [PATCH] big test separation POC

From: Andres Freund <andres(at)2ndquadrant(dot)com>
To: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
Cc: Samrat Revagade <revagade(dot)samrat(at)gmail(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCH] big test separation POC
Date: 2013-07-03 19:44:37
Message-ID: 20130703194437.GG5667@awork2.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2013-07-03 21:07:03 +0200, Fabien COELHO wrote:
>
> >>Here is a v2 which is more likely to work under VPATH.
>
> Here is a POC v4 which relies on multiple --schedule instead of creating
> concatenated schedule files.
>
> --
> Fabien.

> diff --git a/src/test/regress/GNUmakefile b/src/test/regress/GNUmakefile
> index d5935b6..8a39f7d 100644
> --- a/src/test/regress/GNUmakefile
> +++ b/src/test/regress/GNUmakefile
> @@ -86,7 +86,7 @@ regress_data_files = \
> $(wildcard $(srcdir)/output/*.source) \
> $(filter-out $(addprefix $(srcdir)/,$(input_files)),$(wildcard $(srcdir)/sql/*.sql)) \
> $(wildcard $(srcdir)/data/*.data) \
> - $(srcdir)/parallel_schedule $(srcdir)/serial_schedule $(srcdir)/resultmap
> + $(srcdir)/parallel_schedule $(srcdir)/parallel_big_schedule $(srcdir)/resultmap
>
> install-tests: all install install-lib installdirs-tests
> $(MAKE) -C $(top_builddir)/contrib/spi install
> @@ -137,19 +137,43 @@ tablespace-setup:
> ## Run tests
> ##
>
> +# installcheck vs check:
> +# - whether test is run against installed or compiled version
> +# test schedules: parallel, parallel_big, standby
> +# serial schedules can be derived from parallel schedules
> +
> +derived_schedules = serial_schedule serial_big_schedule
> +
> +serial_%: parallel_%
> + echo "# this file is generated automatically, do not edit!" > $@
> + egrep '^(test|ignore):' $< | \
> + while read op list ; do \
> + for test in $$list ; do \
> + echo "$$op $$test" ; \
> + done ; \
> + done >> $@
> +

This won't work on windows all that easily. Maybe we should instead add
a "--run-serially" parameter to pg_regress?

> -installcheck: all tablespace-setup
> - $(pg_regress_installcheck) $(REGRESS_OPTS) --schedule=$(srcdir)/serial_schedule $(EXTRA_TESTS)
> +# after installation, serial
> +installcheck: all tablespace-setup serial_schedule
> + $(pg_regress_installcheck) $(REGRESS_OPTS) \
> + --schedule=serial_schedule $(EXTRA_TESTS)

Why do we use the serial schedule for installcheck anyway? Just because
of max_connections?

Greetings,

Andres Freund

--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kevin Grittner 2013-07-03 19:57:33 Re: refresh materialized view concurrently
Previous Message Cédric Villemain 2013-07-03 19:39:37 Re: [9.4 CF 1] The Commitfest Slacker List