Re: Should we add debug_parallel_query=regress to CI?
От | Andres Freund |
---|---|
Тема | Re: Should we add debug_parallel_query=regress to CI? |
Дата | |
Msg-id | vfhnao6o4tzd3g5f4ao6qgure2fcylk7e42r5qnmxqg3cqmiqk@2q4zlh5pf57i обсуждение исходный текст |
Ответ на | Re: Should we add debug_parallel_query=regress to CI? (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Should we add debug_parallel_query=regress to CI?
|
Список | pgsql-hackers |
Hi, On 2025-03-05 11:19:46 -0500, Tom Lane wrote: > Andres Freund <andres@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
Вложения
В списке pgsql-hackers по дате отправления: