Re: Test to dump and restore objects left behind by regression - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Test to dump and restore objects left behind by regression
Date
Msg-id Z-X9MC8WnYrv8K8F@paquier.xyz
Whole thread Raw
In response to Re: Test to dump and restore objects left behind by regression  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Responses Re: Test to dump and restore objects left behind by regression
List pgsql-hackers
On Thu, Mar 27, 2025 at 06:15:06PM +0100, Alvaro Herrera wrote:
> BTW another idea to shorten this tests's runtime might be to try and
> identify which of parallel_schedule tests leave objects behind and
> create a shorter schedule with only those (a possible implementation
> might keep a list of the slow tests that don't leave any useful object
> behind, then filter parallel_schedule to exclude those; this ensures
> test files created in the future are still used.)

I'm not much a fan of approaches that require an extra schedule,
because this is prone to forget the addition of objects that we'd want
to cover for the scope of this thread with the dump/restore
inter-dependencies, failing our goal of having more coverage.  And
history has proven that we are quite bad at maintaining multiple
schedules for the regression test suite (remember the serial one or
the standby one in pg_regress?).  So we should really do things so as
the schedules are down to a strict minimum: 1.

If we're worried about the time taken by the test (spoiler: I am and
the upgrade tests already show always as last to finish in parallel
runs), I would recommend to put that under a PG_TEST_EXTRA.  I'm OK to
add the switch to my buildfarm animals if this option is the consensus
and if it gets into the tree.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Cross-type index comparison support in contrib/btree_gin
Next
From: Rafael Thofehrn Castro
Date:
Subject: Re: Proposal: Progressive explain