Hi, On 2025-03-05 11:19:46 -0500, Tom Lane wrote: > Andres Freund <and...@anarazel.de> writes: > > Post-commit issues due to debug_parallel_query=regress seem rather common, > > surely not helped by CI/cfbot not flagging them. I wonder if we ought to > > make > > one of the CI tasks use debug_parallel_query=regress, to avoid that problem? > > Yeah, it certainly seems like a test coverage gap.
I decided to use freebsd, as it's a relatively fast task. Additionally I thought it might be interesting to do this testing on the test run that also does debug_write_read_parse_plan_trees etc. I tested it by intentionally not including the revert, and it indeed finds the problem (not that that was really in doubt, but it seemed worth verifying). https://cirrus-ci.com/task/5782413399293952?logs=test_world#L214 > However, we seem to be moving towards a situation where each type of CI run > is a special snowflake that differs in multiple dimensions from other types. > That might make it difficult to figure out which dimension is responsible > for a particular failure. True, but I don't really see an alternative. Having dedicated tasks for testing just debug_parallel_query=regress (and about half a dozen other things) on their own seems like a *lot* of resource usage for the gain. > (OTOH, the same can be said of the buildfarm, and we've survived > regardless. So maybe I'm worried over nothing.) The alternative seems to be to figure out the problem after commit, with similar issues, as you point out. I'd much rather have to spend a minute analyzing why one task triggers an issue than doing so under pressure after commit. I guess we could be add a "standardized" section at the top of each task describing their oddities? Not sure it's worth it. Greetings, Andres Freund
>From 5e75ce6daeb293facbbcff0637d48b87ba40e592 Mon Sep 17 00:00:00 2001 From: Andres Freund <and...@anarazel.de> Date: Wed, 5 Mar 2025 12:08:58 -0500 Subject: [PATCH v1] ci: freebsd: Specify debug_parallel_query=regress A lot of buildfarm animals run with debug_parallel_query=regress, while CI didn't test that. That lead to the annoying situation of only noticing related test instabilities after merging changes upstream. FreeBSD was chosen because it's a relatively fast task. It also tests debug_write_read_parse_plan_trees etc, which probably is exercised a bit more heavily with debug_parallel_query=regress. ci-os-only: freebsd Discussion: https://postgr.es/m/zbuk4mlov22yfoktf5ub3lwjw2b7ezwphwolbplthepda42int@h6wpvq7orc44 --- .cirrus.tasks.yml | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/.cirrus.tasks.yml b/.cirrus.tasks.yml index e7482da1fdd..a4cd0c76e80 100644 --- a/.cirrus.tasks.yml +++ b/.cirrus.tasks.yml @@ -139,7 +139,14 @@ task: CPPFLAGS: -DRELCACHE_FORCE_RELEASE -DENFORCE_REGRESSION_TEST_NAME_RESTRICTIONS CFLAGS: -Og -ggdb - PG_TEST_INITDB_EXTRA_OPTS: -c debug_copy_parse_plan_trees=on -c debug_write_read_parse_plan_trees=on -c debug_raw_expression_coverage_test=on + # Several buildfarm animals enable these options. Without testing them + # during CI, it would be easy to cause breakage on the buildfarm with CI + # passing. + PG_TEST_INITDB_EXTRA_OPTS: >- + -c debug_copy_parse_plan_trees=on + -c debug_write_read_parse_plan_trees=on + -c debug_raw_expression_coverage_test=on + -c debug_parallel_query=regress PG_TEST_PG_UPGRADE_MODE: --link <<: *freebsd_task_template -- 2.48.1.76.g4e746b1a31.dirty
