agora inbox for pgsql-hackers@postgresql.orghelp / color / mirror / Atom feed
[PATCH v15 4/8] Row pattern recognition patch (planner). 249+ messages / 2 participants [nested] [flat]
* [PATCH v15 4/8] Row pattern recognition patch (planner). @ 2024-03-28 10:30 Tatsuo Ishii <ishii@postgresql.org> 0 siblings, 0 replies; 249+ messages in thread From: Tatsuo Ishii @ 2024-03-28 10:30 UTC (permalink / raw) --- src/backend/optimizer/plan/createplan.c | 24 +++++++++++++++----- src/backend/optimizer/plan/planner.c | 3 +++ src/backend/optimizer/plan/setrefs.c | 27 ++++++++++++++++++++++- src/backend/optimizer/prep/prepjointree.c | 4 ++++ src/include/nodes/plannodes.h | 19 ++++++++++++++++ 5 files changed, 71 insertions(+), 6 deletions(-) diff --git a/src/backend/optimizer/plan/createplan.c b/src/backend/optimizer/plan/createplan.c index 5f479fc56c..fe51ad351e 100644 --- a/src/backend/optimizer/plan/createplan.c +++ b/src/backend/optimizer/plan/createplan.c @@ -287,9 +287,11 @@ static WindowAgg *make_windowagg(List *tlist, Index winref, int ordNumCols, AttrNumber *ordColIdx, Oid *ordOperators, Oid *ordCollations, int frameOptions, Node *startOffset, Node *endOffset, Oid startInRangeFunc, Oid endInRangeFunc, - Oid inRangeColl, bool inRangeAsc, bool inRangeNullsFirst, - List *runCondition, List *qual, bool topWindow, - Plan *lefttree); + Oid inRangeColl, bool inRangeAsc, bool inRangeNullsFirst, List *runCondition, + RPSkipTo rpSkipTo, List *patternVariable, List *patternRegexp, + List *defineClause, + List *defineInitial, + List *qual, bool topWindow, Plan *lefttree); static Group *make_group(List *tlist, List *qual, int numGroupCols, AttrNumber *grpColIdx, Oid *grpOperators, Oid *grpCollations, Plan *lefttree); @@ -2699,6 +2701,11 @@ create_windowagg_plan(PlannerInfo *root, WindowAggPath *best_path) wc->inRangeAsc, wc->inRangeNullsFirst, wc->runCondition, + wc->rpSkipTo, + wc->patternVariable, + wc->patternRegexp, + wc->defineClause, + wc->defineInitial, best_path->qual, best_path->topwindow, subplan); @@ -6627,8 +6634,10 @@ make_windowagg(List *tlist, Index winref, int ordNumCols, AttrNumber *ordColIdx, Oid *ordOperators, Oid *ordCollations, int frameOptions, Node *startOffset, Node *endOffset, Oid startInRangeFunc, Oid endInRangeFunc, - Oid inRangeColl, bool inRangeAsc, bool inRangeNullsFirst, - List *runCondition, List *qual, bool topWindow, Plan *lefttree) + Oid inRangeColl, bool inRangeAsc, bool inRangeNullsFirst, List *runCondition, + RPSkipTo rpSkipTo, List *patternVariable, List *patternRegexp, List *defineClause, + List *defineInitial, + List *qual, bool topWindow, Plan *lefttree) { WindowAgg *node = makeNode(WindowAgg); Plan *plan = &node->plan; @@ -6654,6 +6663,11 @@ make_windowagg(List *tlist, Index winref, node->inRangeAsc = inRangeAsc; node->inRangeNullsFirst = inRangeNullsFirst; node->topWindow = topWindow; + node->rpSkipTo = rpSkipTo, + node->patternVariable = patternVariable; + node->patternRegexp = patternRegexp; + node->defineClause = defineClause; + node->defineInitial = defineInitial; plan->targetlist = tlist; plan->lefttree = lefttree; diff --git a/src/backend/optimizer/plan/planner.c b/src/backend/optimizer/plan/planner.c index 38d070fa00..82c370c4b4 100644 --- a/src/backend/optimizer/plan/planner.c +++ b/src/backend/optimizer/plan/planner.c @@ -869,6 +869,9 @@ subquery_planner(PlannerGlobal *glob, Query *parse, wc->runCondition = (List *) preprocess_expression(root, (Node *) wc->runCondition, EXPRKIND_TARGET); + wc->defineClause = (List *) preprocess_expression(root, + (Node *) wc->defineClause, + EXPRKIND_TARGET); } parse->limitOffset = preprocess_expression(root, parse->limitOffset, diff --git a/src/backend/optimizer/plan/setrefs.c b/src/backend/optimizer/plan/setrefs.c index 42603dbc7c..f7abb2be96 100644 --- a/src/backend/optimizer/plan/setrefs.c +++ b/src/backend/optimizer/plan/setrefs.c @@ -210,7 +210,6 @@ static List *set_windowagg_runcondition_references(PlannerInfo *root, List *runcondition, Plan *plan); - /***************************************************************************** * * SUBPLAN REFERENCES @@ -2455,6 +2454,32 @@ set_upper_references(PlannerInfo *root, Plan *plan, int rtoffset) NRM_EQUAL, NUM_EXEC_QUAL(plan)); + /* + * Modifies an expression tree in each DEFINE clause so that all Var + * nodes's varno refers to OUTER_VAR. + */ + if (IsA(plan, WindowAgg)) + { + WindowAgg *wplan = (WindowAgg *) plan; + + if (wplan->defineClause != NIL) + { + foreach(l, wplan->defineClause) + { + TargetEntry *tle = (TargetEntry *) lfirst(l); + + tle->expr = (Expr *) + fix_upper_expr(root, + (Node *) tle->expr, + subplan_itlist, + OUTER_VAR, + rtoffset, + NRM_EQUAL, + NUM_EXEC_QUAL(plan)); + } + } + } + pfree(subplan_itlist); } diff --git a/src/backend/optimizer/prep/prepjointree.c b/src/backend/optimizer/prep/prepjointree.c index 300691cc4d..3220072a51 100644 --- a/src/backend/optimizer/prep/prepjointree.c +++ b/src/backend/optimizer/prep/prepjointree.c @@ -2147,6 +2147,10 @@ perform_pullup_replace_vars(PlannerInfo *root, if (wc->runCondition != NIL) wc->runCondition = (List *) pullup_replace_vars((Node *) wc->runCondition, rvcontext); + + if (wc->defineClause != NIL) + wc->defineClause = (List *) + pullup_replace_vars((Node *) wc->defineClause, rvcontext); } if (parse->onConflict) { diff --git a/src/include/nodes/plannodes.h b/src/include/nodes/plannodes.h index 7f3db5105d..b0e50ae886 100644 --- a/src/include/nodes/plannodes.h +++ b/src/include/nodes/plannodes.h @@ -20,6 +20,7 @@ #include "lib/stringinfo.h" #include "nodes/bitmapset.h" #include "nodes/lockoptions.h" +#include "nodes/parsenodes.h" #include "nodes/primnodes.h" @@ -1096,6 +1097,24 @@ typedef struct WindowAgg /* nulls sort first for in_range tests? */ bool inRangeNullsFirst; + /* Row Pattern Recognition AFTER MACH SKIP clause */ + RPSkipTo rpSkipTo; /* Row Pattern Skip To type */ + + /* Row Pattern PATTERN variable name (list of String) */ + List *patternVariable; + + /* + * Row Pattern RPATTERN regular expression quantifier ('+' or ''. list of + * String) + */ + List *patternRegexp; + + /* Row Pattern DEFINE clause (list of TargetEntry) */ + List *defineClause; + + /* Row Pattern DEFINE variable initial names (list of String) */ + List *defineInitial; + /* * false for all apart from the WindowAgg that's closest to the root of * the plan -- 2.25.1 ----Next_Part(Thu_Mar_28_19_59_25_2024_076)-- Content-Type: Text/X-Patch; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="v15-0005-Row-pattern-recognition-patch-executor.patch" ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
end of thread, other threads:[~2026-06-03 17:41 UTC | newest] Thread overview: 249+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2024-03-28 10:30 [PATCH v15 4/8] Row pattern recognition patch (planner). Tatsuo Ishii <ishii@postgresql.org> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de>
This inbox is served by agora; see mirroring instructions for how to clone and mirror all data and code used for this inbox