agora inbox for pgsql-hackers@postgresql.orghelp / color / mirror / Atom feed
[PATCH v1 1/1] remove autoanalyze corner case 249+ messages / 2 participants [nested] [flat]
* [PATCH v1 1/1] remove autoanalyze corner case @ 2026-04-04 02:49 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 249+ messages in thread From: Nathan Bossart @ 2026-04-04 02:49 UTC (permalink / raw) --- src/backend/postmaster/autovacuum.c | 9 --------- 1 file changed, 9 deletions(-) diff --git a/src/backend/postmaster/autovacuum.c b/src/backend/postmaster/autovacuum.c index 8400e6722cc..857e44034d9 100644 --- a/src/backend/postmaster/autovacuum.c +++ b/src/backend/postmaster/autovacuum.c @@ -3329,15 +3329,6 @@ relation_needs_vacanalyze(Oid relid, scores->max = Max(scores->max, scores->anl); if (av_enabled && anltuples > anlthresh) *doanalyze = true; - - /* - * For historical reasons, we analyze even when autovacuum is disabled - * for the table if at risk of wraparound. It's not clear if this is - * intentional, but it has been this way for a very long time, so it - * seems best to avoid changing it without further discussion. - */ - if (force_vacuum && AutoVacuumingActive() && anltuples > anlthresh) - *doanalyze = true; } if (vac_ins_base_thresh >= 0) -- 2.50.1 (Apple Git-155) --7UU721Dt33Uo3+cq-- ^ 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 -- 2026-04-04 02:49 [PATCH v1 1/1] remove autoanalyze corner case Nathan Bossart <nathan@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