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
signature.asc
Description: PGP signature