Re: Should we add debug_parallel_query=regress to CI? - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Should we add debug_parallel_query=regress to CI?
Date
Msg-id 321570.1741195755@sss.pgh.pa.us
Whole thread Raw
In response to Re: Should we add debug_parallel_query=regress to CI?  (Andres Freund <andres@anarazel.de>)
Responses Re: Should we add debug_parallel_query=regress to CI?
List pgsql-hackers
Andres Freund <andres@anarazel.de> writes:
> On 2025-03-05 11:19:46 -0500, Tom Lane wrote:
>> 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.

Agreed.

> I guess we could be add a "standardized" section at the top of each task
> describing their oddities? Not sure it's worth it.

I think this does need to be documented somewhere/somehow, just so
that people don't waste time focusing on "it's failing on FreeBSD"
when the actual cause is some other thing we happened to load
onto that task.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: [PATCH] pg_stat_activity: make slow/hanging authentication more visible
Next
From: Jeff Davis
Date:
Subject: Re: making EXPLAIN extensible