agora inbox for pgsql-hackers@postgresql.orghelp / color / mirror / Atom feed
[PATCH v2 4/4] xml2: Avoid libxml leaks in pgxml_xpath() error paths 249+ messages / 2 participants [nested] [flat]
* [PATCH v2 4/4] xml2: Avoid libxml leaks in pgxml_xpath() error paths @ 2026-06-01 22:41 Andrey Chernyy <andrey.cherny@tantorlabs.com> 0 siblings, 0 replies; 249+ messages in thread From: Andrey Chernyy @ 2026-06-01 22:41 UTC (permalink / raw) pgxml_xpath() builds an xpath_workspace before returning it to callers. If an ERROR is thrown before the function returns, callers have not received the workspace pointer yet and cannot run cleanup_workspace(). Add local error cleanup for the partially built workspace and the compiled XPath expression. Also check xmlXPathNewContext() before dereferencing the returned context. --- contrib/xml2/xpath.c | 51 +++++++++++++++++++++++++++----------------- 1 file changed, 32 insertions(+), 19 deletions(-) diff --git a/contrib/xml2/xpath.c b/contrib/xml2/xpath.c index 9fe75cb5ff4..283bb51178d 100644 --- a/contrib/xml2/xpath.c +++ b/contrib/xml2/xpath.c @@ -497,36 +497,49 @@ static xpath_workspace * pgxml_xpath(text *document, xmlChar *xpath, PgXmlErrorContext *xmlerrcxt) { int32 docsize = VARSIZE_ANY_EXHDR(document); - xmlXPathCompExprPtr comppath; + xmlXPathCompExprPtr volatile comppath = NULL; xpath_workspace *workspace = palloc0_object(xpath_workspace); workspace->doctree = NULL; workspace->ctxt = NULL; workspace->res = NULL; - workspace->doctree = xmlReadMemory((char *) VARDATA_ANY(document), - docsize, NULL, NULL, - XML_PARSE_NOENT); - if (workspace->doctree != NULL) + PG_TRY(); { - workspace->ctxt = xmlXPathNewContext(workspace->doctree); - workspace->ctxt->node = xmlDocGetRootElement(workspace->doctree); - - /* compile the path */ - comppath = xmlXPathCtxtCompile(workspace->ctxt, xpath); - if (comppath == NULL || pg_xml_error_occurred(xmlerrcxt)) + workspace->doctree = xmlReadMemory((char *) VARDATA_ANY(document), + docsize, NULL, NULL, + XML_PARSE_NOENT); + if (workspace->doctree != NULL) { - if (comppath != NULL) - xmlXPathFreeCompExpr(comppath); - xml_ereport(xmlerrcxt, ERROR, ERRCODE_INVALID_ARGUMENT_FOR_XQUERY, - "XPath Syntax Error"); - } + workspace->ctxt = xmlXPathNewContext(workspace->doctree); + if (workspace->ctxt == NULL) + xml_ereport(xmlerrcxt, ERROR, ERRCODE_OUT_OF_MEMORY, + "could not allocate XPath context"); - /* Now evaluate the path expression. */ - workspace->res = xmlXPathCompiledEval(comppath, workspace->ctxt); + workspace->ctxt->node = xmlDocGetRootElement(workspace->doctree); + + /* compile the path */ + comppath = xmlXPathCtxtCompile(workspace->ctxt, xpath); + if (comppath == NULL || pg_xml_error_occurred(xmlerrcxt)) + xml_ereport(xmlerrcxt, ERROR, ERRCODE_INVALID_ARGUMENT_FOR_XQUERY, + "XPath Syntax Error"); + + /* Now evaluate the path expression. */ + workspace->res = xmlXPathCompiledEval(comppath, workspace->ctxt); + + xmlXPathFreeCompExpr(comppath); + comppath = NULL; + } + } + PG_CATCH(); + { + if (comppath != NULL) + xmlXPathFreeCompExpr(comppath); + cleanup_workspace(workspace); - xmlXPathFreeCompExpr(comppath); + PG_RE_THROW(); } + PG_END_TRY(); return workspace; } -- 2.54.0 --MP_/LMSk9=uMhuQ1QiIJDarDO8G-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 run: *meson_test_world_cmd -- 2.54.0.380.gc69baaf57b --lyfxwjjve3vodszg-- ^ permalink raw reply [nested|flat] 249+ messages in thread
* [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners @ 2026-06-03 17:41 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 249+ messages in thread From: Andres Freund @ 2026-06-03 17:41 UTC (permalink / raw) Without windows-vs is about 10min slower than the others tasks (windows-vs is currently 31m40s, windows-mingw is 20m45s), which makes for a frustrating experience. It seems worth "sacrificing" one of the 20 available concurrent jobs to avoid that. This reduces the time down to about 18m. ci-os-only: windows --- .github/workflows/pg-ci.yml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/.github/workflows/pg-ci.yml b/.github/workflows/pg-ci.yml index 93b17af46df..83ee93ce5d6 100644 --- a/.github/workflows/pg-ci.yml +++ b/.github/workflows/pg-ci.yml @@ -723,8 +723,13 @@ jobs: # Job: Windows - Visual Studio + # + # If we were to execute tests in this job serially, this would be the + # slowest job by a good margin. To avoid that, use a matrix in combination + # with meson test's --slice SLICE/NUM_SLICES mechanism to split the tests + # across two runners. windows-vs: - name: Windows - Visual Studio + name: Windows - Visual Studio - Slice ${{ matrix.slice}}/${{ matrix.num_slices}} needs: [setup, sanity-check] if: | !cancelled() && @@ -732,6 +737,17 @@ jobs: needs.sanity-check.result != 'failure' runs-on: windows-2022 timeout-minutes: 60 + + # As described at the top of the task, split the tests across two runners + # for performance. The gains from additional concurrency diminish + # relatively quickly, due to each instance having to install dependencies + # and build postgres. + strategy: + fail-fast: false + matrix: + num_slices: [2] + slice: [1, 2] + env: # Avoid port conflicts between concurrent tap tests PG_TEST_USE_UNIX_SOCKETS: 1 @@ -885,6 +901,11 @@ jobs: - name: Test world env: + # As described at the top of the task, split the tests across two + # runners for performance. It's not the prettiest to implement this + # by prepending to MTEST_TARGET, but a more complicated solution + # doesn't seem worth it. + MTEST_TARGET: --slice ${{ matrix.slice}}/${{ matrix.num_slices}} ${{env.MTEST_TARGET}} ADDITIONAL_SETUP: | call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\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-06-01 22:41 [PATCH v2 4/4] xml2: Avoid libxml leaks in pgxml_xpath() error paths Andrey Chernyy <andrey.cherny@tantorlabs.com> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.de> 2026-06-03 17:41 [PATCH v9a 22/22] ci: Slice tests on windows-vs across two runners Andres Freund <andres@anarazel.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